Re: Masak's S29 list

2009-03-01 Thread Moritz Lenz
Timothy S. Nelson wrote:
>   Here's my comments on Carl Masak's S29 list.  Note that some of the 
> things that say that they're "now in" something still need a lot of work.
> 
> #  Range objects have .from, .to, .min, .max and .minmax methods
> 
> Now in S32/Containers.pod
> 
> # .contains on Hash and Array
> 
>   Where's this from?

This had been in S03, and was removed since then. You can safely ignore it.

> # Code has a .sig
> 
>   Seems (from what I can tell) to be synonymous with .signature, so I 
> standardised on .signature.

This leads me to another question - afaict we also have .arity on the
code object, but shouldn't that be method on the .signature instead? Do
we have any methods in Code that are not related to the signature?

> # .ACCEPTS and .REJECTS on most everything -- provided by the Pattern role. 
> Likely a mistake to put one under each section, though. Perhaps put one under 
> Object and put a reference to S03.
> 
>   What does Pattern?  Should we have Object does Pattern?

If everything does Pattern, I see no good reason to have a role at all -
just stuff the thing into Object.

> # Block types have .next, .last, .redo and .leave on them. These are also 
> functions, and need to be specced as such.

Ah, that answers my previous question already ;-)

> # .match, .subst and .trans from S05.
> 
>   Now in S32/Str.pod.  But I wasn't sure what subst() returns.

The modified string. (It doesn't do in-place substitution by default).

Cheers,
Moritz

-- 
Moritz Lenz
http://perlgeek.de/ |  http://perl-6.de/ | http://sudokugarden.de/


Re: Masak's S29 list

2009-02-27 Thread Timothy S. Nelson

On Fri, 27 Feb 2009, Moritz Lenz wrote:


# Code has a .sig

Seems (from what I can tell) to be synonymous with .signature, so I
standardised on .signature.


This leads me to another question - afaict we also have .arity on the
code object, but shouldn't that be method on the .signature instead? Do
we have any methods in Code that are not related to the signature?

[reorg]

# Block types have .next, .last, .redo and .leave on them. These are also
functions, and need to be specced as such.


Ah, that answers my previous question already ;-)


	No it doesn't.  Block and Code are different (see S02).  But have a 
look over the S32/Callable.pod document, and you may find that you have an 
answer.  Also, some of the things that I wasn't able to cope with on masak's 
list may be relevant here.



# .ACCEPTS and .REJECTS on most everything -- provided by the Pattern role.
Likely a mistake to put one under each section, though. Perhaps put one under
Object and put a reference to S03.

What does Pattern?  Should we have Object does Pattern?


If everything does Pattern, I see no good reason to have a role at all -
just stuff the thing into Object.


	Exactly, but I thought I'd better ask; I assumed it really went 
somewhere else, and I just hadn't understood.



# .match, .subst and .trans from S05.

Now in S32/Str.pod.  But I wasn't sure what subst() returns.


The modified string. (It doesn't do in-place substitution by default).


Spec modified.

:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-



Re: Masak's S29 list

2009-02-26 Thread Timothy S. Nelson

On Thu, 26 Feb 2009, David Green wrote:


On 2009-Feb-26, at 7:46 pm, Timothy S. Nelson wrote:

# Object has .print and .say.
[...]


My question is, would we be better off having the string conversion routine 
for arrays worry about the input/output record/field separators, rather 
than the IO object?  The downside I can see is that you couldn't have 
separate separators for different IO objects; you'd have to code specially 
if you wanted that functionality.


What about having separators that exist in different scopes?  Objects could 
define their own separators, or if they don't, default to those defined on 
the IO item, which in turn could default to whatever is defined in the 
current block, working outwards from there.


	This is interesting, but I think separators should probably just be 
defined in one place, whether this be Object, scopes, or IO.


This may also mean we don't need .print and .say methods on Object.  Am I 
missing the reason why such methods would exist, other than to allow certain 
objects to define their own special distinctions between printing and saying 
(presumably because simply adding a newline wouldn't be suitable)?
In that case, all the object would need to do is to define its own 
record-separator.


	I would've suggested this, but this seems to be widely used.  The 
specs write things like:


(for 1..100 { $_ if .prime}).say

	I suspect 99% of objects will use the .print and .say methods from 
Object, and simply override stringification if they need to change things.


:)


-
| Name: Tim Nelson | Because the Creator is,|
| E-mail: wayl...@wayland.id.au| I am   |
-

BEGIN GEEK CODE BLOCK
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y-

-END GEEK CODE BLOCK-



Re: Masak's S29 list

2009-02-26 Thread David Green

On 2009-Feb-26, at 7:46 pm, Timothy S. Nelson wrote:

# Object has .print and .say.
[...]


My question is, would we be better off having the string conversion  
routine for arrays worry about the input/output record/field  
separators, rather than the IO object?  The downside I can see is  
that you couldn't have separate separators for different IO objects;  
you'd have to code specially if you wanted that functionality.


What about having separators that exist in different scopes?  Objects  
could define their own separators, or if they don't, default to those  
defined on the IO item, which in turn could default to whatever is  
defined in the current block, working outwards from there.


This may also mean we don't need .print and .say methods on Object.   
Am I missing the reason why such methods would exist, other than to  
allow certain objects to define their own special distinctions between  
printing and saying (presumably because simply adding a newline  
wouldn't be suitable)?
In that case, all the object would need to do is to define its own  
record-separator.




-David