Re: Structures; etc.
Please redo this discussion with Eu in front of the term "object" when that
is what you mean(e.g. Euobject) even though that would be incorrect in the
interpreter. Otherwise, I cannot separate out when you are using the term
object as in OOP or as in Eu.
From what I can understand, it is fairly evident to me that in an interpretive
language of any kind, the late binding that you speak of is a "feature" of
the interpretive process. If I understand what you are talking about, all the
methods of a class would be renamed in the preprocessor to prevent the
type of confusion that you are speaking of. Since I am right at the edge of
my knowledge on this subject, it is highly probable that I am completely out
in left field on this one.
As for structures, they represent real world data that IS largely contiguous
and has no overhead except that represented by alignment. Objects on the
other hand may be grouped, but have no expectation of contiguity or any
other physical relationship. As long as your OOP implementation is based
on pure Euphoria data types, their can be no expectation of contiguity or
of any other particular physical form. That is fine for pure Euphoria OOP
objects, but not fine when dealing with that real world data. External or
foreign structures as I characterized them may have similar syntax to
Euphoria structures, but their physical form is known and fixed and not
subject to Euphoria's "stateless" data types or shifting internal
representations. For reasonably compact and more flexible calling routines
that are reasonably self-documenting, we must be able to get to this fixed
form(that doesn't mean fixed length) data without the atrocity of print() or the
manually intensive and totally non-logical form of peeks and pokes that lose
all field naming conventions of any sort.
Everett L.(Rett) Williams
rett at gvtc.com
On Sun, 30 Jan 2000 19:53:08 -0800, David Cuny <dcuny at LANSET.COM> wrote:
>Everett Williams wrote:
>
>> ... I think that most of [OOP] could be
>> accomplished through pre-processor if
>> Euphoria had adequate namespace and
>> structure capabilities with built-in type
>> checking for sequences.
>
>That was my thinking when I was writing my 'dot' pre-processor, but
>polymorphism is a problem. For example:
>
> procedure foo( object bar )
> bar.print()
> end procedure
>
>Casting 'bar' as an object causes it to lose any sense of identity. The same
>thing is true if you place the object in a sequence:
>
> s[1].print()
>
>The pre-processor has no clue what class to apply. In fact, you don't know
>what the class of the object is going to be until runtime. To get it to
>work, you need to place all the class methods in a lookup table:
>
> routine print()
> -- code goes here
> end procedure
> set_method( "foo", "print", routine_id("print" ) )
>
>The calls then have to resolve the method at runtime. For example,
>
> bar.print()
>
>become:
>
> call_method( "print", bar, {} )
>
>You don't even need namespaces to implement this, but it does a quite a bit
>of overhead.
>
>> Classes and Object orientation do not answer the
>> need for structures.
>
>It's not clear to me why not. For example:
>
> foo.bar
>
>represents an object's value that can be typed to anything. That should give
>the granularity you're asking for.
>
>Or am I missing something?
>
>-- David Cuny
|
Not Categorized, Please Help
|
|
