Re: [P6L] Closed Classes Polemic (was Re: What the heck is a submethod (good for))
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote: On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote: I just don't want people who merely write a module or class to be able to prevent people who actually use that module or class from using, extending, or poking around in it. Sounds kind of like Linus's opinion of close-source modules. If they exist and work, he's not going to break them, but he's not going to do *anything* to specially support them. I mostly agree, but I'm not talking about the *license* of the code. I don't think that's clear to everyone reading this thread, so I think I should clarify. Regardless of the license, the author of a class or module should not be able to close off that class or module from people using that class or module who want to poke around in its guts at runtime, regardless of the license or availability of the source code. Allowing authors to say This is my namespace and you cannot touch it or This is my class and you cannot touch it or derive from it or decorate it or apply roles to it is silly, because they'll do stupid and wrong things that the rest of the world will have to work around forever, regardless of the license of their code. By all means write efficient code and well-encapsulated code and document your interfaces and intentions appropriately, but if you want to write generic and reusable code, don't optimize for situations which you can't possibly have profiled because no one has written the code for them yet. We should not encourage that. -- c
Re: Thoughs on Theory.pm
On 10/13/05, Dave Whipp [EMAIL PROTECTED] wrote:
I started thinking about the in general, unverifiable programmatically
bit. While obviously true, perhaps we can get closer than just leaving
them as comments. It should be possible to associate a
unit-test-generator with the theory, so I can say:
theory Ring(::R) {
...
axiom associative(R ($a, $b, $b)) {
is_true( ((a+b)+c) - (a+(b+c)) eqv R(0) );
}
...
}
And then say for type T, please generate 1000 random tests of T using
axioms of Ring.
The points about hand-crafted edge-case tests are good, but that's not
to say that this isn't a good idea. Putting the properties inline
with the theory is good documentation (plus, as you say, it could be
used to generate pre- and postconditions).
By the way, Haskell already did this.
http://www.haskell.org/ghc/docs/latest/html/libraries/QuickCheck/Test.QuickCheck.html
:-)
Luke
Re: Custom Metaclass and Inheritance of Class Methods
== CONCLUSION / WRAP-UP So, now that I have sufficiently bored you all to tears, I will do a quick re-cap of the main question, and the possible solutions. Should metaclasses be inherited along normal class lines? Meaning that if Foo uses a custom metaclass, and Bar isa Foo, then Bar also uses that metaclass. If we say yes, then I think it is clear that in order to get a sane method and predictable resolution order the custom metaclass would always need to precede the inherited eigenclass in the superclass list. (see the last example above). If we say no, then we need to introduce another anyonomous class into our mix, which we call an 'x' class. The 'x' class would need to use a breath-first dispatch order in order to produce a sane and predictable method resolution order. I would like to expand on my position in the discussion Steve and I had, which is the no position. The crux of my view is that Foo is an instance of some custom metaclass. Bar is an instance of Class (for the sake of argument). Foo and Bar are unrelated, save for the fact that instances created by Bar's new() function will have access to all the behaviors and state that instances created by Foo's new() function will have. This is why I also feel that class methods shouldn't have the same MRO as instance methods, but that's a moot discussion. Rob
Should roles and classes be merged?
In the discussions I've had with Steve, one thing that always nagged me - what's the difference between a class and a role? I couldn't fix it in my head why there were two separate concepts. Steve, yesterday, mentioned to me that in the metamodel that he's got so far, Class does Role. This means that you can have Class A does Class B, and it will DWIM. Additionally, Larry has said that he wants to be able to instantiate a role. This makes gut-sense to me. A role is really just a class snippet, complete or not. You can compose these snippets together to make a larger class. Or, in many cases, you can just instantiate the snippet and have a viable instance. You can also have an incomplete snippet, just as you can have an incomplete class. This could be useful for things like interfaces. Now, you can have your class inherit from another class, compose itself from other classes, or both! It's completely up to you. You can have your roles in an inheritance hierarchy, and it will all just DWIM. What this means is that classes and roles both quack, swim, and lay eggs. They're both just ducks. Given that, there's no need for two separate concepts in the implementation. It just makes for a more complex implementation. I need to stress that I'm not suggesting that the keyword role be removed. It won't be the first time we have keywords that mean the same thing, just with a little sugar added. It definitely improves maintainability to have separate keywords for separate ideas, even if they're implemented identically. Thanks, Rob
Translitteration and combining strings and array references
Yesterday I spend some hours getting pugs to understand translitterations with multiple ranges in each pair. E.g. foobar.trans( a-z = n-za-n ); By accident I tested something like: foobar.trans( ['a' .. 'z'] = n-za-m ); and it didn't work. The problem is that ['a' .. 'z'] gets stringified to 'a b c d ...' which gets 'b' translated to the third letter in the right hand side. Is this supposed to work and if so how should the code differ between foobar.trans( ['a' .. 'b'] = '12'); # a=1, b=2 foobar.trans( a b = 123 ) # a=1, ' '=2, b=3 Same problem ocurs if left hand side is a string and right hand side is an array reference but in this case the code implementing trans can see it. -- Peter Makholm | Why does the entertainment industry wants us to [EMAIL PROTECTED] | believe that a society base on full surveillance http://hacking.dk | is bad? | Do they have something to hide?
Re: Should roles and classes be merged?
On Fri, Oct 14, 2005 at 09:08:45 -0400, Rob Kinyon wrote: couldn't fix it in my head why there were two separate concepts. The difference between a class and a role is in the eyes of their consumer - the way in which a class gets new behavior (inheritence, mixin, or role composition style) is fundamentally the thing that determines whether the consumed thing is a class or a role. Ofcourse, to encourage correct use of a consumable unit of behavior, one can use class or role. However, there is more to it, conceptually - roles make much more sense when parametrized over other types, while classes make more sense unparametrized, due to the way they are used. Last I heard there only roles were allowed to be parametrized, but there really isn't any technical difference between classes and roles in this respect either. Frankly I think that classes make just as much sense when parametrized, but i don't really mind parametrizing roles that are really classes to make anonymous classes. This way it is clear that there can never be uninstantiatable classes around. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me kicks %s on the nose: neeyah! pgpSXywhAFpZI.pgp Description: PGP signature
Re: Proposal to make class method non-inheritable
Stevan Little [EMAIL PROTECTED] writes: Piers, On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote: We definitely have two instances of A since, B.isa(::A). We also have a fragile implementation of count. :) Sorry, I purposefully made it a kludge as that is usually the way the example is shown in most tutorials about class methods. So, let me see if I have this straight here. You're arguing that, because people are often foolish, we should make it harder to be clever? And you're using a deliberately broken example as grist to your mill? Doesn't sound all that Perlish to me. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/
Re: Should roles and classes be merged?
On Fri, Oct 14, 2005 at 09:08:45AM -0400, Rob Kinyon wrote: : What this means is that classes and roles both quack, swim, and : lay eggs. They're both just ducks. Given that, there's no need for two : separate concepts in the implementation. It just makes for a more : complex implementation. I don't think they'll end up the same, quite. : I need to stress that I'm not suggesting that the keyword role : be removed. It won't be the first time we have keywords that mean the : same thing, just with a little sugar added. It definitely improves : maintainability to have separate keywords for separate ideas, even if : they're implemented identically. Certainly a different keyword can be used to convey a different intent. And because there's a different intent, we can have different defaults for them, at minimum. But I think it goes a little deeper than that. Not to put too fine a point on it, classes want to be open, and roles want to be closed. Let's not forget that the main point of roles is to commit to units of behavior that can be composed into classes (and other roles) at compile time. It's your basic mutable/immutable distinction. The compiler can rely on immutable values not changing. Now, we've said you can use a role as if it were a class, but you do it by generating an anonymous class of the same name. Er...yeah...something like that... Going the other direction, you could also use a class as if it were a role, but only by taking a snapshot of its current value. If you're planning to modify your base class after that, you'd better be using inheritance rather than composition, or the derived class won't see the change to the base class, and that would be unfortunate. It's bad enough that you might have to notify all the existing objects that one of its base classes has been modified. Doing that notification to objects of classes that have composed roles with compile-time assumptions would be a nightmare of pessimization. The first implementation of Perl 6 might not make use of optimizations based on compile-time composition, but we need to leave that door open. Generics are somewhat orthogonal to the mutable/immutable distinction, except that they're a better fit for roles because someone has to choose when to instantiate them, and they're easier to understand with early binding rather than late binding. So another way to view the role/class distinction is that roles have eager semantics while classes have lazy semantics. I expect it's possible to do lazy generics, but I would put it in the category of hard things that should be possible. Do I make myself perfectly muddy? :-) Larry
Re: Should roles and classes be merged?
On 10/14/05, Larry Wall [EMAIL PROTECTED] wrote: : I need to stress that I'm not suggesting that the keyword role : be removed. It won't be the first time we have keywords that mean the : same thing, just with a little sugar added. It definitely improves : maintainability to have separate keywords for separate ideas, even if : they're implemented identically. Certainly a different keyword can be used to convey a different intent. And because there's a different intent, we can have different defaults for them, at minimum. But I think it goes a little deeper than that. Not to put too fine a point on it, classes want to be open, and roles want to be closed. Let's not forget that the main point of roles is to commit to units of behavior that can be composed into classes (and other roles) at compile time. It's your basic mutable/immutable distinction. The compiler can rely on immutable values not changing. Ok. So, in essence, a role is a class that defaults to being closed and a class is a role that defaults to being open. Am I rephrasing you correctly? If so, then they're really the same beast under the hood, just with different default behaviors. Going the other direction, you could also use a class as if it were a role, but only by taking a snapshot of its current value. If you're planning to modify your base class after that, you'd better be using inheritance rather than composition, or the derived class won't see the change to the base class, and that would be unfortunate. As you said in the recent class methods thread, it won't be the first time the programmer would be surprised that the computer did exactly what it was told to do. If you choose to compose, you're fixing the behaviors/state at the time of composition, regardless of what happens after composition. If you choose to inherit, you're not fixing anything (save when you choose to close). It's bad enough that you might have to notify all the existing objects that one of its base classes has been modified. Doing that notification to objects of classes that have composed roles with compile-time assumptions would be a nightmare of pessimization. The first implementation of Perl 6 might not make use of optimizations based on compile-time composition, but we need to leave that door open. Why would that notification need to be done? I, the programmer, chose to compose class A into class B. If I then change class A, I do -not- want class B to see those changes. Granted, it's an unmaintainable pile of dreck, but it's MY unmaintainable pile of dreck. And, Perl shouldn't get in the way of my ability to create piles of dreck. I think inheritable class methods are horrid, but I do agree that Perl should give you as much rope as you want. Rob
Re: Translitteration and combining strings and array references
On Fri, Oct 14, 2005 at 08:38:55AM +0200, Peter Makholm wrote: : Yesterday I spend some hours getting pugs to understand : translitterations with multiple ranges in each pair. E.g. : : foobar.trans( a-z = n-za-n ); : : By accident I tested something like: : : foobar.trans( ['a' .. 'z'] = n-za-m ); : : and it didn't work. : : The problem is that ['a' .. 'z'] gets stringified to 'a b c d ...' : which gets 'b' translated to the third letter in the right hand side. Hmm, why is stringification getting involved at all? We're intending transliteration to work with multi-codepoint sequences of various sorts, so the canonical representation of the data structure can't be simple strings. Actually, it looks like the bug is probably that = is forcing stringification on its left argument too agressively. It should only do that for an identifier. One other quibble is that we're switching ranges in character classes to use .. instead of -, so trans should use the same convention. : Is this supposed to work and if so how should the code differ between : : foobar.trans( ['a' .. 'b'] = '12'); # a=1, b=2 : foobar.trans( a b = 123 ) # a=1, ' '=2, b=3 Actually, the [...] is somewhat gratuitous. Should work with parens too. In fact, it should work with a bare range object on the left: foobar.trans( 'a' .. 'b' = '12'); # a=1, b=2 : Same problem ocurs if left hand side is a string and right hand side : is an array reference but in this case the code implementing trans can : see it. Overzealous = stringification, I think. .trans can use a string as a list by splitting it, but the underlying structures must be lists. Thanks for working on this! Do you know any more people like you? :-) Larry
Re: Proposal to make class method non-inheritable
Piers, On Oct 14, 2005, at 12:14 PM, Piers Cawley wrote: Stevan Little [EMAIL PROTECTED] writes: On Oct 12, 2005, at 5:22 AM, Piers Cawley wrote: We definitely have two instances of A since, B.isa(::A). We also have a fragile implementation of count. :) Sorry, I purposefully made it a kludge as that is usually the way the example is shown in most tutorials about class methods. So, let me see if I have this straight here. You're arguing that, because people are often foolish, we should make it harder to be clever? No, more that people have been lead down the wrong paths all too often based on limitations of language implementation. And that Perl 6 should be moving to correct this problem. Sure that might be un- Perlish in the sense that we are not leaving every way to do it open. But at some point I think you need to shake off the old accumulated crud and start fresh, even if that new way might go contrary to what some people have been conditioned to think. I also do not believe that I am making it harder, as much as I am making it different. Change is hard, but it *is* inevitable. I think Perl 6's OO system has the potential to be to OO programming what Perl 5, etc was to text processing. This, I believe, is in large part due to the fact that Perl 5 had such a slim object system, and Larry intended (based on what I have read in A12) to start fresh from the ground up. That, coupled with Perl's tendency to borrow the best from everywhere, and you have the potential for a really great OO system. And you're using a deliberately broken example as grist to your mill? The example is the canonical example for class methods/attributes, and yes it is broken. However, it's broken-ness only serves to illustrate, what I think is, the misunderstanding of the usefulness of class methods in general. One only needs to take a quick sampling of some of the more popular CPAN modules which sport an OO interface to see that all to often class methods are (ab)used to get what amounts to procedural modules with inheritence. Doesn't sound all that Perlish to me. Perl is many different things to different people, this is part of it's beauty as a language. Perl also has the unique ability to be able to re-invent itself on a regular basis (shell-scripts, CGI, bioinformatics, what next??). I personally think that the definition of what is Perlish and what is not Perlish is not only highly subjective, but ever changing. So I guess what I am saying here is thank you, as I will take that as a compliment ;) Stevan
Re: Re(vised): Proposal to make class method non-inheritable
On Fri, Oct 14, 2005 at 01:43:39PM +1100, Stuart Cook wrote:
: On 14/10/05, Stevan Little [EMAIL PROTECTED] wrote:
: So anyway, here are a few ideas, in no particular order:
:
: method bark (::Dog $d:) { ... }
: # not sure if this notation is already taken or not
:
: method bark ($Dog $d:) { ... }
: # not sure I like this one myself, but to me it helps to re-
: enforce the singleton nature of the class instance
:
: method bark (Dog) { ... }
: # this would be similar to functional languages where the
: parameter matches a value, not the type of a value.
: # The user would then be forced to use $?CLASS inside (this one is
: probably too much BD)
:
: classmethod bark { ... }
: # you can't get more specific than this :)
:
: Okay, thats all for now, however, be on the lookout for some other
: mails on the specifics of class method dispatch. If we are going to
: do it, we need to do it right.
:
: How about:
:
: method bark (Dog ::K:) { ... }
:
: Where ::K must hold a class that is a subclass of Dog. Or 'is a
: subtype of', or 'does', or whatever the most correct term is in this
: context.
Look guys, I want it to just consistently be
method bark (Dog $d) {...}
regardless of how instantiated the dog is. Think of partially
instantiated subroutines via .assuming. A sub is a sub regardless of
how much it's been curried. So who cares if it's a complete Dog or
a partial Dog, or a completely generic Dog? Nobody cares until you
try to call a specific method that relies on some specific attribute.
If you call a sub with an incomplete definition, you should be prepared
to handle the exception. If you call a method with an incomplete object,
you should be prepared to handle the exception.
Of course, by that argument, $d should be considered defined even if
it's a completely uninstantiated class object. With subs the final
proof of actual well-definedness (not to be confused with .defined())
is whether it can be bound to a particular set of arguments. It's a
rather lazy definition of well-definedness. I'm proposing that
all objects follow the same model of not caring how well they're
defined until you actually try to use them for something. I don't
think I care any more about whether classes test as defined or not.
It's like reality--there are a lot of complex problems where the
simplest way to simulate them is via reality itself, and all other
simulations are guaranteed to be slower.
But we have to think a bit more about the notion of currying class
objects into real objects, or something approaching real objects.
This only reinforces my view that all the meta stuff for Dog must
be via the .meta or the associated package. There is no Class object.
It's a false dichotomy. Class is a role that manages partially
instantiated objects, just as Routine (or whatever it is these
days) is a role that manages partially instantiated sub calls.
And they mostly manage by delegation to .meta.
Larry
Lazy Generics side-bar (was Re: Should roles and classes be merged?)
Larry,
On Oct 14, 2005, at 1:28 PM, Larry Wall wrote:
Generics are somewhat orthogonal to the mutable/immutable distinction,
except that they're a better fit for roles because someone has to
choose when to instantiate them, and they're easier to understand
with early binding rather than late binding. So another way to view
the role/class distinction is that roles have eager semantics while
classes have lazy semantics. I expect it's possible to do lazy
generics, but I would put it in the category of hard things that
should be possible.
I am not 100% sure what you mean by lazy generics vs. eager
generics. But in the current metamodel prototype I have implemented,
what I believe to be, lazy generics. It works like so.
Say we have a generic Unit class, which needs a type (::T) for it's
value:
class Unit[::T] {
has ::T $.value;
}
Now I am assuming that a class body is a closure (which surely it is)
and that it usually just gets evaluated right away. What if we defer
that evaluation?
Lets de-sugar the above example a little:
my $Unit = sub (::T) {
class Unit[::T] {
has ::T $.value;
}
};
Now we have not yet actually created any Unit classes yet (generic or
otherwise). Instead we have a closure which given the right set of
parameters, can create specific instances of the Unit class which are
parameterized.
Now we create our Unit[Int] class like this:
my $unit_int = Unit[Int].new();
Which would be just sugar for this:
my $unit_int = $Unit.(Int).new();
Again, I am not sure if this is what you mean by lazy generics or not.
Stevan
Book RFC - Migrating to Perl 6
I'd like to start by saying DON'T PANIC! I'm not going to write a book on Perl 6 ;-) Luckily we have people with much more enlish-fu, structured-thought-fu, and general get-it-done-fu... Now let's talk a bit about them: Today Geoff Broadwell raised a book idea for discussion on #perl6. The result was this wiki page: http://pugs.kwiki.org/?MigratingToPerl6 Essentially Geoff's idea was that the book will come out around the same time as Perl 6.0.0, and will be the guide for perl 5 programmers looking to swallow the Perl 6 pill as easily as possible. The wiki page illustrates how we think it will be structured, and how we think it should be written. Please post feedback and criticism on the list, #perl6 or the wiki page. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: : neeyah! pgpeiR4qHQZMr.pgp Description: PGP signature
Re: Translitteration and combining strings and array references
[EMAIL PROTECTED] (Larry Wall) writes:
On Fri, Oct 14, 2005 at 08:38:55AM +0200, Peter Makholm wrote:
: Yesterday I spend some hours getting pugs to understand
: translitterations with multiple ranges in each pair. E.g.
:
: foobar.trans( a-z = n-za-n );
:
: By accident I tested something like:
:
: foobar.trans( ['a' .. 'z'] = n-za-m );
:
: and it didn't work.
:
: The problem is that ['a' .. 'z'] gets stringified to 'a b c d ...'
: which gets 'b' translated to the third letter in the right hand side.
Hmm, why is stringification getting involved at all? We're intending
transliteration to work with multi-codepoint sequences of various
sorts, so the canonical representation of the data structure can't
be simple strings.
Actually, it looks like the bug is probably that = is forcing stringification
on its left argument too agressively. It should only do that for an
identifier.
The code I'm lookin at is in pugs/src/perl6/Prelude.pm around line 380:
method trans (Str $self: *%intable) is primitive is safe {
my sub expand (Str $string is copy) {
...
}
my sub expand_arrayref ( $arr is copy ) {
...
}
my %transtable;
for %intable.kv - $k, $v {
# $k is stringified by the = operator.
my @ks = expand($k);
my @vs = $v.isa(Str) ?? expand($v) !! expand_arrayref($v);
[EMAIL PROTECTED] = @vs;
}
[~] map { %transtable{$_} // $_ } $self.split('');
}
One other quibble is that we're switching ranges in character classes to
use .. instead of -, so trans should use the same convention.
Ok.
: Is this supposed to work and if so how should the code differ between
:
: foobar.trans( ['a' .. 'b'] = '12'); # a=1, b=2
: foobar.trans( a b = 123 ) # a=1, ' '=2, b=3
Actually, the [...] is somewhat gratuitous. Should work with parens too.
In fact, it should work with a bare range object on the left:
foobar.trans( 'a' .. 'b' = '12'); # a=1, b=2
Works too.
Thanks for working on this! Do you know any more people like you? :-)
No, after seeing what happend to Lintilla I've kept clear from cloning
companies.
--
Peter Makholm | What if:
[EMAIL PROTECTED] | IBM bought Xenix from Microsoft instead of buying
http://hacking.dk | DOS?
Re: Translitteration and combining strings and array references
Larry Wall skribis 2005-10-14 10:43 (-0700): Actually, it looks like the bug is probably that = is forcing stringification on its left argument too agressively. It should only do that for an identifier. Would it work to call this process autoquoting, instead of stringification? I'm assuming other means of stringification do not involve interpreting barewords. One other quibble is that we're switching ranges in character classes to use .. instead of -, so trans should use the same convention. Wasn't there going te be a feature to trans entire strings? i.e. 'foo' = 'bar', where foo is a single thing replaced by bar. Does this not exclude any possibility of specifying ranges in strings? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: Translitteration and combining strings and array references
On Fri, Oct 14, 2005 at 08:49:50PM +0200, Peter Makholm wrote:
: The code I'm lookin at is in pugs/src/perl6/Prelude.pm around line 380:
:
: method trans (Str $self: *%intable) is primitive is safe {
:
: my sub expand (Str $string is copy) {
: ...
: }
:
: my sub expand_arrayref ( $arr is copy ) {
: ...
: }
:
: my %transtable;
: for %intable.kv - $k, $v {
: # $k is stringified by the = operator.
Interesting comment. I wonder if it's true. The key shouldn't
be stringified by = unless it's an identifier, but even if = is
behaving itself, shoving it into a hash key will stringify for
a normal hash.
: my @ks = expand($k);
: my @vs = $v.isa(Str) ?? expand($v) !! expand_arrayref($v);
Nit: that probably wants to be an MMD dispatch eventually so we can handle
things that aren't quite Str or Array.
: [EMAIL PROTECTED] = @vs;
: }
:
: [~] map { %transtable{$_} // $_ } $self.split('');
: }
I think the sig is abusing slurpy hashes, which are really intended
only to sop up unbound named arguments, not a list of object pairs
like this. Filtering through an unshaped hash is going to force
string context on the keys. So either we need to declare a shape
on the hash that allows for non-Str keys (which I'm not sure Pugs
implements yet), or we need to protect these pairs from being processed
as named parameters.
Also, if we go with the syntactic definition of named args we've
been discussing lately on p6l, we'll need to put an extra set of
parens around the pair list, or prefix with == to force it into
the list zone, or pass inside [...]. (And for syntactic named args,
a = probably *should* be enforcing string context on the key.)
Larry
Re: Translitteration and combining strings and array references
On Sat, Oct 15, 2005 at 01:27:58AM +0200, Juerd wrote: : Larry Wall skribis 2005-10-14 10:43 (-0700): : Actually, it looks like the bug is probably that = is forcing : stringification on its left argument too agressively. It should only : do that for an identifier. : : Would it work to call this process autoquoting, instead of : stringification? Yes, autoquoting is what = is supposed to do to its left argument, if it's an identifier. : I'm assuming other means of stringification do not : involve interpreting barewords. Depends on whether you count the stringification done by a slurpy hash on its keys as other means of stringification. That seems to be what's going on here, even though the left side of = isn't an identifier. : One other quibble is that we're switching ranges in character classes to : use .. instead of -, so trans should use the same convention. : : Wasn't there going te be a feature to trans entire strings? i.e. 'foo' : = 'bar', where foo is a single thing replaced by bar. Does this not : exclude any possibility of specifying ranges in strings? Doesn't seem like a big problem. Presumably if you ever really want to translate to or from .., you can make it an endpoint of its own pair in the pair list. On the other hand, I could see .. happening accidentally in a string occasionally. And one can presumably construct ranges with a real .. operator. So maybe the non-quote form of tr/// should always use lists, with a helper function to translate a..z to a list and also carp about the fact that it will break under Unicode. :-) Or maybe the argument is always a list of pair of (list or string), in which case we know the string at that level can be interpreted for .., but a string within a sublist can't. If someone wants to work over the interface for consistency and flexibility, that'd be fine. Larry
Re: Re(vised): Proposal to make class method non-inheritable
Larry,
I have been giving a lot of thought to the way you have been
describing classes lately. I think I understand where you are going
with it, but I need to understand some of the details.
On Oct 14, 2005, at 2:15 PM, Larry Wall wrote:
This only reinforces my view that all the meta stuff for Dog must
be via the .meta or the associated package. There is no Class object.
It's a false dichotomy. Class is a role that manages partially
instantiated objects, just as Routine (or whatever it is these
days) is a role that manages partially instantiated sub calls.
And they mostly manage by delegation to .meta.
If I understand you correctly then, what I have been calling a class
object is just really the thing on the other end of .meta.
When I say class object, I mean some kind of object instance which
contains all the information to describe a class (methods, meta-
attributes, superclass list, etc). This can just as easily be called
a metaclass instance too, it makes no difference to me.
As for the idea that Class is a role that manages partially
instantiated objects, I am not sure i am understanding what you mean
here. I am assuming this is along the lines of the Class's are a
special form of undef idea. In that case I can see where maybe the
Class thing is simply a parameterized role of some kind which has
the following behaviors:
1) it evaluates to undef in an expression
my Dog $fido;
if ($fido) {
# this won't run, $fido is not yet defined
}
2) it acts as a proxy if a method is called on it
my Dog $fido;
$fido .= new();
If this is true, then maybe Class looks something like this:
role Class[MetaClassType $T] {
# evaluate to false in bool context
method prefix:? () { bool::false }
# probably need to overload some other
# operators here too, but I will leave
# that for now
# the AUTOMETH checks for an calls
# any method you attempt to call on
# this particular class
# ( I am not sure about the details
# of the code here, but you get the
# idea I think )
method AUTOMETH { $T.can($_).([EMAIL PROTECTED]) }
}
Then if this were so, then the following:
my Dog $fido;
Would be de-sugared into:
my $fido = Class[Dog].new();
At least this is how I am seeing it currently in my head. Please let
me know if I am way off the mark here, I am trying to understand how
this all will work. Ideally it can fit into the current meta-model
prototype as designed, if not, I have no problem re-writing it again,
but I just need to wrap my head around how this should work.
Thanks much,
Stevan
Standard library for perl6? (graphical primitives)
(I'm mainly interested about graphical primitives, but there are likely
other areas where standard library would be of use.)
If I want to write a crossplatform text-mode application, I could write
it in perl, and know that it will be usable in wide variety of
platforms, as long as I use only standard commands and not any
platform-specific modules etc..
But if I want to write graphics-mode application, I really don't know
what to do. Even if I were to write a simple one, which just draws lines
or puts pixels on screen, I do not know of any good solution.
Java has graphical primitives, but is encumbered by bad licenses.
C doesn't have graphical primitives in standard library, AFAIK.
Perl does have CPAN, but the problem is that there are no standard
modules, and so there can be several modules doing the same thing. perl5
has some standard commands, listed in perlfunc, but that doesn't
include any graphical primitives.
Could it be possible to create a Standard library for perl6, which
would also include graphical primitives (putpixel, getpixel,
getcolordepth, putimage, getimage, copyrectangle)?
Just a basic example:
use 6;
use Stdlib::GraphicalPrimitives;
// check for availability of graphics mode
if (!GraphModeAvailable())) {
print No graphics available, sorry\n;
exit 1;
}
// initialize graph-mode, ask for a 100x100 pixel area
// with 24bit colors to work on
if (!InitGraphics(100, 100, 24)) {
print Couldn't get 100x100x24 graphics area\n;
exit 2;
}
// do something
DrawLine(0, 0, 99, 99);
// ...
--
Markus Laire
