1. Re: More hairsplitting with Ralf
Ralf wrote:
>>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.
Apology accepted. 
But you *still* make the same two errors:
1. You talk about something that doesn't exist as if it is real.
2. You make absolute statements about things that are not necessarily =
true.
For example:
>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.
How exactly did you benchmark your defined structures? You can't, =
because it doesn't exist.
I'll grant you, they *could* be faster. But until they actually exist, =
making a declaration like that is not supportable.
Another example:
>>In any other OOP-language it is also an assignment hidden by a =
preproccesor.
In OOP, assignment is not something "hidden by a preprocessor"; it's =
integral to the language. Operating on the *message* to the object is =
what makes the change.
OK, on to your follow-up comments:
>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 =3D newButton ( {100,100}, GRAY, "CANCEL" )
> foo =3D 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.
I don't think you are talking about OOP, Ralf. A button is not a "custom =
data type." In your example you aren't creating any "objects"; only =
filling in data structures.
Win32Lib uses an "object" approach to accomplish the kinds of things =
that your example is trying to show. It turns out that, in a GUI =
environment such as Win32, using objects is *much* more natural - =
because the underlying environment *is* OO.
In an OOP environment, it *would* be entirely natural to unload a =
created object. Creating buttons that magically disappear at the end of =
a function is much more "unnatural."
>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 ?
No, actually it's not "just a syntactic thing." In Smalltalk, an object =
receives messages, which cause it to execute methods. They are two =
different things.
>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 ?
Um... No.
You are saying that object sequences have more "clarity in usage" than =
handles. I disagree. Here are some examples:
Creating a button:
Ralf's:
button myButton
myButton =3D newButton( {100,100}, GRAY, "CANCEL" )
OO:
integer myButton -- will hold a handle
myButton =3D newButton( {100,100}, GRAY, "CANCEL" )
Changing the button:
Ralf's:
myButton =3D setButton( myButton, BUTTON_PRESSED )
OO:
setButton( myButton, BUTTON_PRESSED )
Copying the button:
Ralf:
button cloneButton
cloneButton =3D myButton
OO:
integer cloneButton -- still a pointer
copyButton( myButton, cloneButton )
Deleting a button:
Ralf:
myButton =3D {} -- or use garbage collection
OO:
kill( myButton )
Even you admitted that an OO approach can be clearer:
>>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...
All in all, I think the argument that an OO has less "clarity in usage" =
doesn't really hold up.
I *do* agree that your approach is faster - but I've pretty much said =
that all along.
-- David Cuny
