.chars, .bytes, etc.

2005-09-24 Thread wolverian
Hi all,

After some thinking it occured to me that the current way of defining
.chars, .bytes and .elems (and whatever else there are) doesn't make any
sense to me. In pugs at least they currently return the amount of units
in question - in any context! Why not define .chars like this:

Context Return value
itemamount of units
listunits themselves

Juerd proposed this list originally, which matches my thinking.

Originally I thought that .elems and .chars were symmetric and both
should behave the same semantically, but now I think that's false - if
there should be an .elems method, leave it at returning an Int at all
times. @foo.elems returning the elements in @foo makes no sense.

-- 
wolverian


signature.asc
Description: Digital signature


Re: .chars, .bytes, etc.

2005-09-24 Thread Juerd
wolverian skribis 2005-09-24 13:45 (+0300):
 Why not define .chars like this:
 Context Return value
 itemamount of units
 listunits themselves

Agreed, of course.

 Originally I thought that .elems and .chars were symmetric and both
 should behave the same semantically

I still think this. They certainly LOOK symmetric.

But .elems isn't needed. At all. [EMAIL PROTECTED] already is the number of
elements, list @foo already is a list of elements. Now, if we're going
to have .elems anyway, then let it be symmetric with .chars. The
difference with @foo without .elems would then be non-Num item context:
item @foo returns [EMAIL PROTECTED], but item @foo.elems returns [EMAIL 
PROTECTED] Still, I'd
prefer not having .elems at all, as it adds nothing but confusion,
regardless of which of the two semantic sets is chosen.


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


k, v

2005-09-24 Thread Juerd
Hashes are full of convenience, and Huffman would be proud:

%hash.keys  %hash.key
%hash.values%hash.value
%hash.kvzip(%hash.keys, %hash.values)

One thing occurred to me: if hashes are worth all this, then why not
abbreviate keys further to k (as in kv), and values to v (as
in kv). This would allow us to rename key to k and value to v
too, resulting in:

%hash.k %hash.k
%hash.v %hash.v
%hash.kvzip(%hash.k, %hash.v)

With hashes and pairs, I don't think there could be any confusion over
the meaning of k and v, just like kv works without explanation. 

(Not having to type alue also makes it easier for a pair to NOT
evaluate to its value, but that's another thread.)


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


Re: k, v

2005-09-24 Thread Uri Guttman
 J == Juerd  [EMAIL PROTECTED] writes:

  J Hashes are full of convenience, and Huffman would be proud:
  J %hash.keys  %hash.key
  J %hash.values%hash.value
  J %hash.kvzip(%hash.keys, %hash.values)

  J One thing occurred to me: if hashes are worth all this, then why not
  J abbreviate keys further to k (as in kv), and values to v (as
  J in kv). This would allow us to rename key to k and value to v
  J too, resulting in:

  J %hash.k %hash.k
  J %hash.v %hash.v
  J %hash.kvzip(%hash.k, %hash.v)

huffman has its limits too. in general having single letter names for
anything is a poor idea. it makes it hard to search for, you limit it to
only one thing that can use that letter, it isn't always easy to
remember what a given letter is, etc. keys and values are short enough
and read much better. kv works because keyvalues is clunky and too
long. i wouldn't have minded .pairs or .each instead of kv. but alias
methods are easy to add. 

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org


Re: k, v

2005-09-24 Thread Juerd
Uri Guttman skribis 2005-09-24 10:37 (-0400):
 huffman has its limits too. in general having single letter names for
 anything is a poor idea. it makes it hard to search for, you limit it to
 only one thing that can use that letter, it isn't always easy to
 remember what a given letter is, etc. keys and values are short enough
 and read much better. kv works because keyvalues is clunky and too
 long. 

This reasoning works for me. Thank you.

 i wouldn't have minded .pairs or .each instead of kv. but alias
 methods are easy to add. 

I'd expect .pairs to return pairs, not keys and values zipped.

Re each, I don't know what to expect: a single pair, or all pairs. Not
what .kv does, anyway.


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