1. Splitting hairs with Ralf
Ralf wrote:
>>David Cuny wrote:
>>
>>into:
>> local[1] =3D local[2] + local[3]
>>Certain operations (such as '&') take *much* longer when you are =
working
>>with a structure instead of a 'pure'=20
>>variable.
>>
>Not true, the overhead is speed is caused by the interpreter not =
knowing the
>structure during pre-compilation.
>If Euphoria would enable structures, they could execute that kind of =
code
>*much* faster.=20
Take a look at your last sentance, Ralf. Whether or not it *should* be =
that way, it *is* in fact slower to do certain operations on elements of =
structures than on a variable - slow enough for me to avoid it, if =
possible.
>>It would certainly not be more "pure", but more "used" is the word =
your
>>looking for. Technically it isn't even called OOP. Four reason why the =
other
>>method is the better choice:
Sorry, Ralf, but I again disagree with most of what you say.
On the plus side, I *do* agree that your method is more efficient - =
something which I was alluding to in my prior statements. Obviously, =
anything built on top of "native" Euphoria functionality is going to be =
slower.
On to the disagreement. Both my example, or the initial example *could* =
have been OOP. Let's look at your argument:
1. ...It would certainly not be more "pure"...
I think my version encapsulates the information better, making it =
"purer". Not more efficient - I never made that claim. But more pure, =
because it hides the actual assignment. In the initial version, a =
function called SetWin() is called to do an action - but the assignment =
portion of the action is external to the method - clearly "less pure."
2. ...but more "used" is the word your [sp] looking for.
No, I think the first example is the more "used" - at least, by =
Euphorians. Mind you, I've not done any statistical analysis on this. =
3. Technically, it isn't even called OOP.
Well, what's OOP?
1. The data is encapsulated in objects.
2. The methods are encapsulated in objects.
3. Methods are passed.
Inheritance, while nice, is *not* a requirement.
I think we can agree that encapsulating *data* in a structure is =
generally acceptable for the first requirement. As you said:
>1) In real oop, we do set something inside the object, but we manage =
the
>data of that object ourselves, in this case the managing of that data =
is the
>job of the library, which has to re-invent dynamic allocation all over
>again.
For encapsulating *methods*, let's imagine that we *did* have a lookup =
table that, when passed a class name and proc name, would return the =
procID of the method:
getMethod( class, method )
Obviously, we need a routine to return the class of an object:
getClass( object )
Continuing this thought experiment, imagine that the inside of the =
routine that I called looked like this:
procedure SetWin( integer object, sequence control, integer =
attribute, sequence value )
integer method
sequence class
-- get the class
class =3D getClass( object )
-- get the proc id from the class
procId =3D getMethod( class, "SetWin" )
-- call the class's proc
call_proc( procID, {object, control, attribute, value} )
end procedure
Looks like "pure" OOP to me - the data and methods are both encapsulated =
by the objects.
The only point left is the last: passing methods. You may disagree with =
my syntax and say that a "pure" method would require a syntax like:
send_method( MyWindow, "btn1", COORDS, {50,20} )
But I didn't ever claim that the example was "pure". By those standards, =
C++ wouldn't even be OOP - something I'm not up to debating.
-- David Cuny
2. Re: Splitting hairs with Ralf
Looking at the subject, you sound a bit offended, and for this I apologize.
I sometimes sound pretty arogant it seems, but just consider it my lack of
expierence, I never ment to sound this way.
>Take a look at your last sentance, Ralf. Whether or not it *should* be that
way, it *is* in fact slower to do certain operations on elements of
structures than on a variable - slow enough for me to avoid it, if possible.
Yes, but you said structures weren't a good idea, because they were
currently very slow in Euphoria, and my point was, defined structures
*would* be fast, unlike undefined structures that we have to use now.
>On to the disagreement. Both my example, or the initial example *could*
have been OOP. Let's look at your argument:
>
>1. ...It would certainly not be more "pure"...
>
>I think my version encapsulates the information better, making it "purer".
Not more efficient - I never made that claim. But more pure, because it
hides the actual assignment. In the initial version, a function called
SetWin() is called to do an action - but the assignment portion of the
action is external to the method - clearly "less pure."
In any other OOP-language it is also an assignment hidden by a preproccesor.
I think an assignment at least shows us, that we do change the object, and
it is really not to the point. The point I made, was that the user now has
control over the data. It could save it to disk, print it out, clone it.
Plus it takes advantage of Euphoria's dynamic allocation and deallocation.
>2. ...but more "used" is the word your [sp] looking for.
>
>No, I think the first example is the more "used" - at least, by Euphorians.
Mind you, I've not done any statistical analysis on this.
Well, neither have I, but doesn't many stuff from the Recent User's
Contribution list use handles. I mean, handles for virtual
screens(HHS-Mode19 Toolkit), for wave-channels (modwave), etc.
>3. Technically, it isn't even called OOP.
>
>Well, what's OOP?
>
>1. The data is encapsulated in objects.
>2. The methods are encapsulated in objects.
>3. Methods are passed.
>
>Inheritance, while nice, is *not* a requirement.
Well, I'm assuming you use an external library to manage your objects and
methods.
And using such a library the development of an object becomes, I must agree,
a bit easier, and produces code which is a bit more clear than it would be
in my case, but the use of the object would be extremely unnaturaly:
procedure msg_box ()
button my_button -- This looks nice!
button foo
...
my_button = newButton ( {100,100}, GRAY, "CANCEL" )
foo = setButton ( my_button, BUTTON_PRESSED )
-- foo is now a clone of my_button, but in pressed state.
..
end procedure
It looks nicer I think, but besider that: when the object gets out of scope
(end of procedure) euphoria unloads it, just like any other atom, sequence
or custom data type. A routine to unload would be unnatural.
>The only point left is the last: passing methods. You may disagree with my
syntax and say that a "pure" method would require a syntax like:
>
> send_method( MyWindow, "btn1", COORDS, {50,20} )
>
>But I didn't ever claim that the example was "pure". By those standards,
C++ wouldn't even be OOP - something I'm not up to debating.
To be honiest, I care less what is would be more "pure", rather what would
be more "clear", "convient" and "consistent". I know the orginal SmallTalk
sends messages instead of methods, but thats just a syntactic thing, isn't
it ?
So there is our choice, what we consider more important:
Clearity in object-code --> Handles
together with a library that manages it all.
Clearity in usage & better performance --> Object sequences.
Agreed ?
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
