Euphoria types of the POLL
Peter Robinson explicit asked to post comments outside of the POLL thread
and to that I am posting the comments here.
Peter Robinson wrote:
> Variation A2:
>
> type customer( sequence x )
> fields
> integer x[1] id
> sequence x[2] name
>
> Variation B2:
>
> type customer( sequence x )
> fields
> integer id -- x[1] is assumed
> 4. Regardless of your answer to the previous question:-
>
> (a) which variation do you prefer? {ANSWER A2 or B2]
>
> (b) would you support the introduction of both together?
> [ANSWER YES OR NO]
>
Does A2 allow you to put arbitrary expressions like
java methods?
For example:
type customer( sequence x )
fields
integer x[1] id
sequence x[2] name
sequence x[3] address
sequence x[2] & x[3] nameAndAddress
end fields
end type
> 5. Regardless of your previous answers, if syntax with naming were introduced,
> would you prefer the elements in an object declarded with this type to be
> accessible
> by:- [ANSWER a or b]
>
> (a) dot access e.g. customer_x.name; or
>
> (b) subscript/indexes e.g. customer_x[name]
>
As long as 'name' is of a limited bracket scope I would be happy. I think
5b may be more flexible. This is what C++ and Java has over EUPHORIA. We
have to declare big scope integer constants like D_NAME which function as
field names and therefore
we need to prepend things like D_ and hope they are not taken already.
This proposed change will mean a lot less constant declarations as
well as shorter field names. As long as the scope is more limited.
What happens inside the brackets? Is name of global scope or will there be
a special bracket scope that only goes for indexing a instance of that type
where name is declared in the field.
object x1
customer customer_x
customer_x[name] = "Sam"
x1[name] = "Who" -- should give an error message
sequence name -- Is there a problem now?
Can we do things like customer_x[name..$] or customer_x[name+1]?
Will name conflict with name space outside? Will I be unable to
use a variable called name?
Right now if you declare 'boolean b' the interpreter will take that
as meaning 'call boolean( b ) each time b changes.' Assuming you
have defined type boolean( ) somewhere in your program. I would
extend this as follows:
Allow type to have more than one argument as the arguments preceeding
the last would all be routine ids to other types.
type map( integer keytype_t, integer itemtype_t, sequence x )
...
end type
Then you could declare several maps like:
map of sequences and integers nametoAgeMap
array of maps of integers and sequences OtherStructure
If the interpreter could take things like
'array of integers ai'
as to mean 'Call array( ai, routine_id("integer") ) on each change'
If a type routine declaration could also accept other routine ids as
extra arguments and the type syntax handling could be modified as just
described then you keep more code of in the .e files and less in the
interpreter backend and have even more flexibility:
type array( atom typeid, object x )
if not sequence(x) then return 0 end if
for i = 1 to length(x) do
if not call_func( typeid, {x[i]} ) then
return 0
end if
end for
return 1
end type
type map( atom preimaget, atom imaget, sequence s )
fields
sequence keys
sequence items
end fields
for i = 1 to length(s) do
if not call_func( preimaget, {s[keys][i]} ) or not call_func( imaget,
{s[items][i]} ) then
return 0
end if
end for
return 1
end type
array of customers customer_list
map of sequences and integers name_to_customer_index_lookup_table
Shawn Pringle
|
Not Categorized, Please Help
|
|
