Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

.thingies in contexts

0 views
Skip to first unread message

Juerd

unread,
Sep 26, 2005, 11:40:45 AM9/26/05
to perl6-l...@perl.org
We've had several discussions of .chars and .elems, and I said
something about objects in certain contexts.

In the discussion about objects, I left item and list context out,
because in those contexts, always the object is just itself.

One thing makes .chars and .elems look symmetric: they are both plural.
We are used to having plural things, like arrays, behave such that in
Num context, they evaluate to their number of things, and in list
context, they evaluate to the things themselves.

I'd like to have that be a global and consistent thing in Perl 6's
design: whenever a method name is plural, it behaves like this, and vice
versa.

String context is free, but in general, the elements joined by some kind
of separator is expected. Unspecified item context is expected to result
in an arrayref, but it could very well be an object too. This allows
HTTP::Message::headers to return an HTTP::Headers object, which of
course evaluates to a number of headers in Num context.

Do note that it doesn't allow HTTP::Message::headers to return an
HTTP::Headers object in *list* context, because in list context, it has to
return the individual elements, because the name is plural. It'll have
to decide to use $headers.headers all by itself.

Summarized:

The expected behavior for any .thingies (method name in plural) is:

Context Expectated evaluation

item Something that does Array, e.g. an object or an arrayref
Num Number of thingies
Str Thingies all stringified, then joined
list The thingies themselves

In fact, the behaviors for Num and Str are implied by item returning
something that does Array. Making it explicit helps to understand the
structure.

I believe that this kind of consistency will contribute to overall ease
of programming and understanding.

Perhaps there are other word forms and expected return values. I'm a bit
careful with asking this question, because I expect something to be said
about imperatives and boolean return values, and I like split too much
although you could argue that split should be called "chunks" and
behave as described in this message.


Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

0 new messages