Re: Euphoria types of the POLL
Shawn wrote:
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]
>
Shawn wrote at this point:
>>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
The simple answer is NO, the last field above is not a variation within the
questions. Of course, adding sequence x[4] nameAndAddress would be OK, but you
would have to perform any concatenation action or test separately.
I know Java (or thought I did!) but I had difficulty working out what your
variation - sequence x[2] & x[3] nameAndAddress - was intended to represent in
Java. I thought you meant this Euphoria equivalent, which could be added to the
type block:-
if not equal( nameAndAddress, name & address ) return false
but even in that example, surely you would want to add spaces or other
delimiters between the two strings.
Or do you mean:-
sequence of sequence nameAndAddress
Your example has the expression on the LHS of a declaration, which is confusing
me a little. Do you intend it to mean:-
test for concatentation
or
perform concatentation when initialising
or
perform concatentation at some other time ????
Initialising variables is another question. It's not in the poll.
The poll questions primarily address declaring elements inside a sequence in the
same way as they are declared outside a sequence (obviously, a form of
identification of the elements, either implicit or explicit must be added or
assumed).
The poll said:
> 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]
>
Shawn wrote:
>> 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?
I think the questions leave this open for discussion and future polling if
necessary. On the one hand, you could say, why allow named subsripts within a
type block unless they are limited to that type? On the other hand, you could
say, we now allow named constants outside the type block that are actually only
intended to apply to a particular type of object, with no syntax (other than
comments or some naming convention like the one you suggest) to distinguish them.
So there are issues either way. But those issues may become irrelevant if the dot
notation is preferred.
Shawn, your remaining post relates to ideas going beyond the current poll, so
I'll leave it to others to respond to those. In running the poll I try not to mix
my own views with the form of the questions. I hope the comments above clarify
where possible.
Regards
Peter Robinson
|
Not Categorized, Please Help
|
|
