1. Re: More hairsplitting with Ralf
David Cuny wrote:
>1. You talk about something that doesn't exist as if it is real.
The possibility is real, and the way ex.exe would handle it is pretty
predictable.
The preproccesor within ex.exe converts the code into a stack, with the
pointers to the piece of code to be executed. Within this procces, all
variables are replaces by 32-bit protected mode addreses, however: a slice
is looked-up in real time. (logically, it has to be looked up in runtime).
With a *fixed* structure however, it doesn't have to lookup the addres of
the selected element. It NEVER changes, and thus can be embedded right into
the stack. Elements of a *fixed* structure would have the *precize* same
speed as an unsliced sequence or an atom.
This however is an theory, RDS could, if they would support this, choose to
use the only other method. Looking up in real-time, however it is more
complex to code *and* it would be slower anyway, I can be pretty sure, they
wouldn't go that way.
>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.
Yes, we can benchmark it, here's the code to do so. There is no faster, more
logical and convient way to provide support for structures than within the
preproccesor handling it as normal variables.
Here's the code:
--
atom i, o
i = time ()
for index = 1 to 1000000
o = i
end for
? time() - 0
--
end for
>I'll grant you, they *could* be faster. But until they actually exist,
making a declaration like that is not supportable.
I've just motivited my statement I guess.
>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.
Integral to the language.. in most languages OOP is done by a preproccesor.
But an assigment means.. you change its value, you set it to a new value.
Also you have to admit, that even your method assigns/change the object, and
without any assignment the object would not change.. only in your method the
user is not the one to assign, you do that for him, but it is an
assignment.. just like in any other languages. As well as you hide it or
not, stuffing it in other routines.. etc.
>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 = 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.
>
>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.
The custom data type yes.. to check/validate the values of an object.
I've created the object by asking for the creation of it.. newButton ( ..)
Then I store its data for usage.
>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.
I am using objects, and the only reason why your method is more appealing to
the win32 platform is because all windows dll are written in C and thus use
handles for the same reason as they use pointers.. because C, unlike
Euphoria, does not have a true dynamic data storage system. Euphoria hides
pointers, and handles. And yes you could work with pointers in Euphoria, and
yes you could work with handles.
To be compatible to the dll's I know you have to use handles, but on its
own, it makes little sence to re-invent a wheel, when your could use the
wheel you are already used, which also has better performance.
>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."
Not for an Euphorian. An object is a value just like an atom or sequence,
and using different or custom scope methods would be very inconsequent.
>>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.
Not for the programmer.
>>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 = newButton( {100,100}, GRAY, "CANCEL" )
>
> OO:
> integer myButton -- will hold a handle
> myButton = newButton( {100,100}, GRAY, "CANCEL" )
>
>Changing the button:
> Ralf's:
> myButton = setButton( myButton, BUTTON_PRESSED )
> OO:
> setButton( myButton, BUTTON_PRESSED )
>
>Copying the button:
> Ralf:
> button cloneButton
> cloneButton = myButton
> OO:
> integer cloneButton -- still a pointer
> copyButton( myButton, cloneButton )
>
>Deleting a button:
> Ralf:
> myButton = {} -- or use garbage collection
> OO:
> kill( myButton )
>
>Even you admitted that an OO approach can be clearer:
The way you handle the scope of the objects, and the way you pass are
independent from any OO standard. Its for the language to decide that. Can I
now assume you disagree with scope rules of variables (like atoms, object
(OOP) and sequences) in Euphoria ? Or that you would prefer routines to copy
one value from one variable to another ?
>>>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.
It *does* make it more complex. Different scope rules for objects, special
routines for copying, or storing the actual object data, etc. It would bring
back the one thing that Euphoria had banded from its syntax, namely handles.
(Pointers are also handles off course)
Thats the reason BTW why I mind, the way I/O is done in Euphoria, it so
DOS-like...
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
