Re: Structures; etc.
----- Original Message -----
From: Michael Nelson <mike-nelson-ODAAT at WORLDNET.ATT.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Sunday, January 30, 2000 4:38 AM
Subject: Structures; etc.
> There seems to be a recurring demand for structures--in Euphoria terms,
> fixed-length sequences with type specified for each element and named
access
> to the elements, preferably with dot notation.
Who said anything about fixed length? Implementing named and typed elements
within an "object" is just a natural extension of Euphoria's existing named
and
typed elements (atom, integer, sequence). There's no reason to abandon the
dynamic
sizing of sequences just because they may be incorporated as part of a
larger group of elements. Likewise, there seems to be no logical reason for
abandoning the ability to type check integers just because you are using
that integer variable as part of a
larger variable.
> I'm not sure I see the point in doing this if we are going to stop there.
> No doubt implementing structures in the Eu interpreter would require
> extensive reprogramming. If Rob were to invest that much time and effort
> into redesigning the language, why only go half way to object orientation?
> Add access control, methods, and some form of inheritance and you have a
> true OOP language: E++. Is this the direction we want Euphoria to go?
Extensive reprogramming? Consider this: every pre-defined or user-defined
type already carries with it an identifier as to type. If they didn't, you
wouldn't
get error messages when making an incorrect assignment. Therefore, the only
addition would seem to be some kind of container object to hold a list of
variables,
and when assignment is made to an object in the container, perform the
existing type check just as it does when the member is a stand-alone
variable.
> My inclination is to vote NO--and no one can accuse me of being anti-OOP.
> For those of us who want structures without having to hand code types for
20
> to 50 sequence elementsand want dot notation, how about a
> preprocessor--perhaps along the lines of David Cuny's Dot preprocessor.
Two reasons this isn't practical:
1. Rob has no choice but to fix the namespace problems. In so doing,
he will either implement dot notation or some other workable arrangement.
Whatever method he chooses, it is sure to be better than a pre-processor.
2. Calling the built-in type checking is _much_ faster than calls to user
type()
functions, which is what you would have if using a pre-processor. Remember,
even if your "structure" is as simple as {x,y} where x and y are integers,
any
assignment to x, y or {x,y} must be run thru a user-written type() function,
which
then calls the built in integer type check for each. That can result in a
major performance hit, especially if instead of two integers you are working
with arrays
of hundreds or thousands of integers/atoms.
Irv
|
Not Categorized, Please Help
|
|
