OpenEuphoria

RE: Why UDT's aren't used.

• Posted by "Kat" <gertie at visionsix.com> Jun 04, 2004
• 533 views

On 4 Jun 2004, at 10:13, Patrick Barnes wrote:

> 
> 
> >The only reason he SHOULD be surprised is because he hadn't been
> >using the language.  Anyone that has every tried to build a decent type
> >check on a sequence would know that the performance hit is horrible.
> >
> >I as well understand why, as I assume most others do.  But
> >understanding has simply lead us to not using it. Using good strong
> >type checking can turn a 1 second load program into a program that
> >appears to simply hang for several minutes.  I know, cause I've
> >done it before.  I've avoided type defining ever since.  I don't think
> >I have seen any code of Robs where he defines a type on a
> >sequence in a table like manner.
> >
> <SNIP>
> >-----------------------
> >PhoneBook PB
> >
> >PB = {}
> ></eucode>
{{{

> >
> >Now who wants to write code to actually items to the phone book?
> >Better yet, Who would dare to use this with type checking enabled?
> 
> Certainly not me... I hate to think how much overhead is involved, 
> especially if something horrific is done like import this phone book from a
> file... <shudders>
> 
> I wish something could be done about structuring types. The hardest part of
> your
> type code (and same for any structured type) is the PhoneBook item.... It
> would
> be nice if there was a way to reference elements of a structured type by name.
> The only way to do this at the moment is to define constants, and use
> var[ELEM_NAME]. There are problems with type-checking on large structured
> types,
> because like with arrays at the moment, we have to check every sequence every
> time something changes.
> 
> Something that would be nice:
> type phoneBookItem( structured sequence x)
>        ...some form of special declaration giving name and type of each 
> element to be in x...
> end type
> 
> The two main problems with this:
> 1. Assigning a literal to a structured sequence will be very tricky.
> 2. It's likely to be too radical for Rob to approve.

Thinking radically.......

add the var as a dynamic include pointer. Or a string execution item. 
Fetching from it or saving to it is a function call. It runs code only on
itself, it
returns things such as it's value or error code. It could call other code that 
you can write to perform actions when some var is changed. As for returning 
*native* types, point to predefined types in shared memory.

But then, RobC sees no use for string execution or for dynamic includes. 
Drat it. Vote time again?

Kat