Re: Masak's S29 list
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
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
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
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
