[32620] in Perl-Users-Digest
Perl-Users Digest, Issue: 3894 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Mar 6 16:14:18 2013
Date: Wed, 6 Mar 2013 13:14:07 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 6 Mar 2013 Volume: 11 Number: 3894
Today's topics:
Re: some random remarks about Moose::Manual::Concepts <ben@morrow.me.uk>
Re: some random remarks about Moose::Manual::Concepts <rweikusat@mssgmbh.com>
Re: some random remarks about Moose::Manual::Concepts <ben@morrow.me.uk>
Re: some random remarks about Moose::Manual::Concepts <rweikusat@mssgmbh.com>
Re: some random remarks about Moose::Manual::Concepts <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 5 Mar 2013 21:47:22 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <ao5i0a-h3q1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> >> > Ben Morrow <ben@morrow.me.uk> writes:
> >> >> Attributes in Perl should in general be wrapped in accessor methods,
> >> >> whether those methods are considered 'public' or 'private' (or some sort
> >> >> of C++ish 'protected'),
>
> [...]
>
> >> This (what Ben Morrow wrote) is actually a sufficiently mind-boggling
> >> idea that a more detailed comment seems appropriate. The first
> >> observation about the 'every attribute access should go through an
> >> accessor method' statement would be that this is impossible because
> >> there's no way to implement 'an accessor method' if the accessor
> >> method itself needs an accessor method to access the attribute.
> >
> > Obviously the accessor methods themselves need to access the attribute
> > directly; my point was that nothing else should.
>
> Yes. And because of this, the 'class' is actually just a structure
> composed of 'some perl object' (in the sense of scalar, array, ...)
> which provides access to some set of named properties via methods and
> some part really shouldn't belong to the class but does for 'weird
> reasons'.
I don't understand why you seem to think methods which only call other
methods (rather than accessing attributes directly) are not part of the
'real class'. AFAIC, a class has a documented public interface; how that
interface is implemented is not relevant.
> > Suppose I am selling books. So I have a
> > whole lot of Book objects, each with 'price' and 'discount' properties,
> > and a method on Book
> >
> > sub charge {
> > my ($self) = @_;
> >
> > my $price = $self->{price};
> > my $discount = $self->{discount};
> >
> > $price - POSIX::floor( ($price * $discount) / 100);
> > }
> >
> > Now suppose some of my books are part of a standardised series, where
> > the pricing for each book in the series is a property of the Series the
> > Book belongs to rather than the Book itself. What I want to be able to
> > do is
> >
> > package Book::InSeries;
> > use parent "Book";
> >
> > sub price { $_[0]->series->price }
> > sub discount { $_[0]->series->discount }
> >
> > and have the ->charge method above continue to work; as written, this is
> > not possible because ->charge is accessing the attributes directly.
>
> NB: This is a contrived example but it already has some of properties
> I was writing about.
It is slightly contrived, but it is derived from a real system I am
working on.
> The problem with this is that the 'charge' method is really not at all
> related to books but a general calculation. A 'book' is just a thing
> with two properties, price and discount, and 'book from a series' is
> also something which has these two properties.
OK, so how would you implement the 'charge' function, in Perl? As a
plain function? That works for the case where there is only one possible
charge calculation, but what if I also have other types of object with
different charging rules?
> It is merged in the
> book class in order to get 'access' (in German, one would call this
> 'von hinten durch die Brust ins Auge', 'shot from behind through the
> chest into an eye') to the charge method which is attached to book and
> this seems to be the path of least resistance, given the properties of
> the existing implementation.
'Given the properties of the existing implementation' is a very common
constraint. It's not unusual to be in the position of wanting to
subclass an existing class, often a CPAN class which cannot necessarily
be modified. This can be made rather easy or rather difficult depending
on how the original class was implemented.
Also, I was not assuming these were the only properties and methods on
Book. Books might have a whole lot of other properties (a title, an
ISBN, one or more authors, a cover picture...) which also apply to the
book-in-a-series.
> The charge method really shouldn't be a method at all but a 'generic
> function' (intentional misuse, I re-read some stuff about CLOS
> yesterday) which works with any object capable of being queried for a
> price and a discount and both 'individually priced book' and 'book
> from a series' should be objects of different classes reacting to
> 'price' and 'discount' messages the charge method can work with
> because interface and implementation are 'naturally separate' in
> Perl-OO, anyway (especially considering the somewhat shady guy next
> door who sells used handkerchiefs he acquired in some not-to-be-named
> way. These also have a price and a discount and he would really like
> to 're-use' the charge function, possibly without asking for
> permission first ...).
So again, in Perl 5 (which doesn't have generic functions or multimethod
dispatch), how would you implement it?
One of the things Moose makes easy is moving code like this into roles.
That means that otherwise-unrelated classes can consume the role in
order to reuse the code. It's not as good as full multi-dispatch (you're
still only dispatching on the type of the first argument) but it's an
extremely useful way of avoiding unnecessary distortions of the
inheritance hierarchy just to share code.
> I'll try to contrast this with a real example (somewhat simplified):
[...]
> As it turned out to be, the situation that a single linking object is
> updated more than one time during an 'event cycle' can also occur. In
> order to deal with that, a hash keeping track of which objects are
> already in the updated objects array was added to the Interest
> class. This (or any other rearranagement of the way the Interest
> object keeps its internal data) could be accomplished without
> affecting any other part of the whole mechansism because the interface
> offered by the class wasn't affected by it. Instead of changing the
> Interest object implementation, another option had been to subclass it
> and add the 'hash lookup' part by overloading the 'add updated' method
> in a way CLOS would call 'an around method', only invoking the
> original 'add updated' in case the object to be added wasn't already
> added. While such a hypothectical subclass could put its instance data
> into a new slot of the 'general object representation' used by the
> base class (an anonymous array), it could as well just store it in any
> other 'convenient' way and it doesn't have (and doesn't need) any
> knowledge about how the 'base class' uses its slots of the array
> reference, not even what these slots 'are' (eg, their number and their
> 'names').
Well, in Perl the only other 'convenient way' I know of is to use
inside-out objects, that is, to maintain a global hash mapping objects
to properties; and they are not very easy to work with. (I did some
experiments once with the idea of keeping attributes in closed-over
lexicals, but didn't get it to the point of being useful.)
> One of the problems with 'OOP' is that simple, contrived examples are
> almost always useless except for demonstrating whatever they were
> supposed to demonstrate while even relatively simple 'real examples',
> as the one described above (certainly a lot less than 100 LOC), are
> already so hideously complicated that using them as an explanation is
> next to impossible :-}.
I didn't entirely follow the bit I snipped, but I don't think it was
really relevant (please correct me if I'm wrong). I believe all you were
saying is that, had you chosen to subclass Interest, you could have done
so without needing to know anything about where it kept its attributes;
but you didn't explain how you would have achieved that.
Ben
------------------------------
Date: Wed, 06 Mar 2013 13:47:40 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <87a9qgk5c3.fsf@sapphire.mobileactivedefense.com>
NB: I'm trying to ignore sideline issues (such as 'Mindless ad hocery
is a very common OO design pattern' :-) in order to keep this somewhat
focussed on 'properties of the Perl object model'.
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
[...]
>> Yes. And because of this, the 'class' is actually just a structure
>> composed of 'some perl object' (in the sense of scalar, array, ...)
>> which provides access to some set of named properties via methods and
>> some part really shouldn't belong to the class but does for 'weird
>> reasons'.
>
> I don't understand why you seem to think methods which only call other
> methods (rather than accessing attributes directly) are not part of the
> 'real class'. AFAIC, a class has a documented public interface; how that
> interface is implemented is not relevant.
Because that's how it happens to work in Perl (or in other OO system
structured around 'message passing'): The only thing which is really
specific to 'the class' is the object representation it uses. Any of
these 'methods invoking other methods' will happily work with any
object which implements the necessary methods, no matter what its
class happens to be.
Somewhat stupid contrived example demonstrating that:
---------------
package Teabag;
sub new
{
my $weight;
$weight = $_[1];
return bless(\$weight, $_[0]);
}
sub weight
{
return ${$_[0]};
}
sub contents
{
return 'tea';
}
sub name
{
return 'teabag';
}
sub unit
{
return 'grams';
}
sub statement
{
printf("The %s contains %s %s of %s.\n",
$_[0]->name(), $_[0]->weight(), $_[0]->unit(), $_[0]->contents());
}
package Gun;
sub new
{
my $weight;
$weight = $_[1];
return bless(\$weight, $_[0]);
}
sub weight
{
return ${$_[0]};
}
sub contents
{
return 'gunpowder';
}
sub name
{
return 'gun';
}
sub unit
{
return 'pounds';
}
package main;
my $gun = Gun->new(3.5);
Teabag::statement($gun);
------------
[...]
>> The problem with this is that the 'charge' method is really not at all
>> related to books but a general calculation. A 'book' is just a thing
>> with two properties, price and discount, and 'book from a series' is
>> also something which has these two properties.
>
> OK, so how would you implement the 'charge' function, in Perl? As a
> plain function? That works for the case where there is only one possible
> charge calculation, but what if I also have other types of object with
> different charging rules?
I was refering to the specific example you posted, not to any
conceivable other example you could have posted instead: The 'charge'
function has a single input, namely, 'an object', and the only
requirements for this object are 'it has to implement the price and
discount methods' and not 'it must be a book' (or its class must have
been derived from the 'Book' class). By putting this charge function
into the 'Book' package, you're actually just expressing your opinion
that it should only be used for 'Book objects' but this voluntary
reduction in 'general usefulness' is neither technically required nor
necessarily sensible (since the same 'charging rules' could be applied
to other objects-for-sale as well).
[...]
> One of the things Moose makes easy is moving code like this into roles.
> That means that otherwise-unrelated classes can consume the role in
> order to reuse the code.
As I've shown with my 'silly example' above, otherwise-unrelated
classes can 'reuse the code' without any mechanism for doing so if the
code isn't really dependent on something which is specific to a
particular class. And the 'set of messages' objects of a class
understand isn't.
[...]
>> I'll try to contrast this with a real example (somewhat simplified):
> [...]
>> As it turned out to be, the situation that a single linking object is
>> updated more than one time during an 'event cycle' can also occur. In
>> order to deal with that, a hash keeping track of which objects are
>> already in the updated objects array was added to the Interest
>> class. This (or any other rearranagement of the way the Interest
>> object keeps its internal data) could be accomplished without
>> affecting any other part of the whole mechansism because the interface
>> offered by the class wasn't affected by it. Instead of changing the
>> Interest object implementation, another option had been to subclass it
>> and add the 'hash lookup' part by overloading the 'add updated' method
>> in a way CLOS would call 'an around method', only invoking the
>> original 'add updated' in case the object to be added wasn't already
>> added. While such a hypothectical subclass could put its instance data
>> into a new slot of the 'general object representation' used by the
>> base class (an anonymous array), it could as well just store it in any
>> other 'convenient' way and it doesn't have (and doesn't need) any
>> knowledge about how the 'base class' uses its slots of the array
>> reference, not even what these slots 'are' (eg, their number and their
>> 'names').
[...]
>> One of the problems with 'OOP' is that simple, contrived examples are
>> almost always useless except for demonstrating whatever they were
>> supposed to demonstrate while even relatively simple 'real examples',
>> as the one described above (certainly a lot less than 100 LOC), are
>> already so hideously complicated that using them as an explanation is
>> next to impossible :-}.
>
> I didn't entirely follow the bit I snipped, but I don't think it was
> really relevant (please correct me if I'm wrong). I believe all you were
> saying is that, had you chosen to subclass Interest, you could have done
> so without needing to know anything about where it kept its attributes;
> but you didn't explain how you would have achieved that.
That was actually a half-way ill thought out afterthought and the
'main' part of the statement was what you snipped. This was supposed
to be the smallest example of 'a real class' I could come up with which
provides 'behaviour' to its users (and whose instances need to keep
'state information' 'in some way' in order to provide this behaviour)
and not 'a panhandle to a set of named attributes'.
------------------------------
Date: Wed, 6 Mar 2013 19:04:40 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <8jgk0a-34h2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
>
> [...]
>
> >> Yes. And because of this, the 'class' is actually just a structure
> >> composed of 'some perl object' (in the sense of scalar, array, ...)
> >> which provides access to some set of named properties via methods and
> >> some part really shouldn't belong to the class but does for 'weird
> >> reasons'.
> >
> > I don't understand why you seem to think methods which only call other
> > methods (rather than accessing attributes directly) are not part of the
> > 'real class'. AFAIC, a class has a documented public interface; how that
> > interface is implemented is not relevant.
>
> Because that's how it happens to work in Perl (or in other OO system
> structured around 'message passing'):
Perl's OO system is not particularly structured around message passing,
in the Smalltalk sense. It's actually not that easy to create an object
which accepts arbitrary messages and (say) passes them on to some other
object, especially if you want ->can and so on to work properly on the
proxy.
> The only thing which is really
> specific to 'the class' is the object representation it uses. Any of
> these 'methods invoking other methods' will happily work with any
> object which implements the necessary methods, no matter what its
> class happens to be.
Hmm. It sounds to me as though you are the one trying to turn objects
into fancy structs. One of the points of OO is method dispatch or
polymorphism or whatever you want to call it: that you can send the same
message to different objects and they will behave differently. The only
(reasonable) ways to achieve that in Perl are to put the method
implementations directly into the class concerned, or to put them into a
superclass.
> Somewhat stupid contrived example demonstrating that:
> ---------------
> package Teabag;
>
> sub new
> {
> my $weight;
>
> $weight = $_[1];
> return bless(\$weight, $_[0]);
> }
>
> sub weight
> {
> return ${$_[0]};
> }
>
> sub contents
> {
> return 'tea';
> }
I take it you consider these constants to be part of the internal
representation of the object?
>
> sub name
> {
> return 'teabag';
> }
>
> sub unit
> {
> return 'grams';
> }
>
> sub statement
> {
> printf("The %s contains %s %s of %s.\n",
> $_[0]->name(), $_[0]->weight(), $_[0]->unit(), $_[0]->contents());
> }
>
> package Gun;
>
[...snip implementation...]
>
> package main;
>
> my $gun = Gun->new(3.5);
>
> Teabag::statement($gun);
> ------------
>
> [...]
>
> >> The problem with this is that the 'charge' method is really not at all
> >> related to books but a general calculation. A 'book' is just a thing
> >> with two properties, price and discount, and 'book from a series' is
> >> also something which has these two properties.
> >
> > OK, so how would you implement the 'charge' function, in Perl? As a
> > plain function? That works for the case where there is only one possible
> > charge calculation, but what if I also have other types of object with
> > different charging rules?
>
> I was refering to the specific example you posted, not to any
> conceivable other example you could have posted instead:
You didn't answer the question: given the example as I originally posted
it, how would you implement the charge function?
Now suppose I have a different situation. I have Book and Book::InSeries
objects as before, which should use this charge function:
sub charge {
my ($self, $count) = @_;
my $price = $self->price;
my $discount = $self->discount;
$count * ($price - $price * $discount);
}
In the Book case, ->price and ->discount are properties; in the InSeries
case, they are taken from the object's ->series property. I also have
Bulk objects, which should use this charge function:
sub charge {
my ($self, $count) = @_;
my $base = $self->price;
my $discount = $self->discount;
my $cutoff = $self->cutoff;
my $price = $count > $cutoff ? $base * $discount : $base;
$count * $price;
}
How would you implement these three classes? (I am genuinely interested
in your answer to this question.)
> The 'charge'
> function has a single input, namely, 'an object', and the only
> requirements for this object are 'it has to implement the price and
> discount methods' and not 'it must be a book' (or its class must have
> been derived from the 'Book' class).
Agreed.
> By putting this charge function
> into the 'Book' package, you're actually just expressing your opinion
> that it should only be used for 'Book objects' but this voluntary
> reduction in 'general usefulness' is neither technically required nor
> necessarily sensible (since the same 'charging rules' could be applied
> to other objects-for-sale as well).
I'm doing more than that: I'm stating 'this is the charge function that
should be used on Books'. Given that, as you say, it's a fairly generic
function, it might be sensible to move it into a role so that Book and
other classes can consume that role, but I still, at some point, have to
establish a link between 'Book objects' and 'this particular charge
function'.
> > One of the things Moose makes easy is moving code like this into roles.
> > That means that otherwise-unrelated classes can consume the role in
> > order to reuse the code.
>
> As I've shown with my 'silly example' above, otherwise-unrelated
> classes can 'reuse the code' without any mechanism for doing so if the
> code isn't really dependent on something which is specific to a
> particular class. And the 'set of messages' objects of a class
> understand isn't.
Your example was using entirely manual dispatch: you already knew you
wanted to call Teabag::statement. The interesting question is 'how do
you locate the right function to call', not 'how do you call it once
you've done so'.
> >> I'll try to contrast this with a real example (somewhat simplified):
> > [...]
> >> As it turned out to be, the situation that a single linking object is
> >> updated more than one time during an 'event cycle' can also occur. In
> >> order to deal with that, a hash keeping track of which objects are
> >> already in the updated objects array was added to the Interest
> >> class. This (or any other rearranagement of the way the Interest
> >> object keeps its internal data) could be accomplished without
> >> affecting any other part of the whole mechansism because the interface
> >> offered by the class wasn't affected by it. Instead of changing the
> >> Interest object implementation, another option had been to subclass it
> >> and add the 'hash lookup' part by overloading the 'add updated' method
> >> in a way CLOS would call 'an around method', only invoking the
> >> original 'add updated' in case the object to be added wasn't already
> >> added. While such a hypothectical subclass could put its instance data
> >> into a new slot of the 'general object representation' used by the
> >> base class (an anonymous array), it could as well just store it in any
> >> other 'convenient' way and it doesn't have (and doesn't need) any
> >> knowledge about how the 'base class' uses its slots of the array
> >> reference, not even what these slots 'are' (eg, their number and their
> >> 'names').
Again, you snipped what I considered a rather important question: how
would you have done this, specifically?
> > I didn't entirely follow the bit I snipped, but I don't think it was
> > really relevant (please correct me if I'm wrong). I believe all you were
> > saying is that, had you chosen to subclass Interest, you could have done
> > so without needing to know anything about where it kept its attributes;
> > but you didn't explain how you would have achieved that.
>
> That was actually a half-way ill thought out afterthought and the
> 'main' part of the statement was what you snipped. This was supposed
> to be the smallest example of 'a real class' I could come up with which
> provides 'behaviour' to its users (and whose instances need to keep
> 'state information' 'in some way' in order to provide this behaviour)
> and not 'a panhandle to a set of named attributes'.
OK. In that case I didn't understand what the example was supposed to
demonstrate. How, beyond being more complicated, is that example
different from the simple examples we have been discussing?
Ben
------------------------------
Date: Wed, 06 Mar 2013 20:03:15 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <87k3pki9do.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> Ben Morrow <ben@morrow.me.uk> writes:
>> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>> >> Ben Morrow <ben@morrow.me.uk> writes:
>>
>> [...]
>>
>> >> Yes. And because of this, the 'class' is actually just a structure
>> >> composed of 'some perl object' (in the sense of scalar, array, ...)
>> >> which provides access to some set of named properties via methods and
>> >> some part really shouldn't belong to the class but does for 'weird
>> >> reasons'.
>> >
>> > I don't understand why you seem to think methods which only call other
>> > methods (rather than accessing attributes directly) are not part of the
>> > 'real class'. AFAIC, a class has a documented public interface; how that
>> > interface is implemented is not relevant.
>>
>> Because that's how it happens to work in Perl (or in other OO system
>> structured around 'message passing'):
>
> Perl's OO system is not particularly structured around message passing,
> in the Smalltalk sense.It's actually not that easy to create an object
> which accepts arbitrary messages and (say) passes them on to some other
> object, especially if you want ->can and so on to work properly on the
> proxy.
It is also not particularly 'structured around message passing' in the
'Royal Mail' sense and 'we' haven't even considered the possibility that
'message passing' could also refer to Mr Message fainting or dying,
just with a trivial misspelling. There are any number of possible
interpretations of any word or combination of words I wrote which make no
sense and you've ably demonstrate that you're capable of finding them.
>>> The only thing which is really specific to 'the class' is the
>>> object representation it uses. Any of
>>> these 'methods invoking other methods' will happily work with any
>>> object which implements the necessary methods, no matter what its
>>> class happens to be.
>
> Hmm. It sounds to me as though you are the one trying to turn objects
> into fancy structs.
Because of some properties of an example you invented?
> One of the points of OO is method dispatch or
> polymorphism or whatever you want to call it: that you can send the same
> message to different objects and they will behave differently. The only
> (reasonable) ways to achieve that in Perl are to put the method
> implementations directly into the class concerned, or to put them into a
> superclass.
This is another point which - so far - hasn't been discussed and isn't
relevant.
>
>> Somewhat stupid contrived example demonstrating that:
>> ---------------
>> package Teabag;
>>
>> sub new
>> {
>> my $weight;
>>
>> $weight = $_[1];
>> return bless(\$weight, $_[0]);
>> }
>>
>> sub weight
>> {
>> return ${$_[0]};
>> }
>>
>> sub contents
>> {
>> return 'tea';
>> }
>
> I take it you consider these constants to be part of the internal
> representation of the object?
I consider this sufficient in the context of a simple example
demonstrating what I intended to demonstrate: Subroutines which don't
do anything with objects except 'invoke some methods' can work with
any Perl object, its class notwithstanding.
>>
>> [...]
>>
>> >> The problem with this is that the 'charge' method is really not at all
>> >> related to books but a general calculation. A 'book' is just a thing
>> >> with two properties, price and discount, and 'book from a series' is
>> >> also something which has these two properties.
>> >
>> > OK, so how would you implement the 'charge' function, in Perl? As a
>> > plain function? That works for the case where there is only one possible
>> > charge calculation, but what if I also have other types of object with
>> > different charging rules?
>>
>> I was refering to the specific example you posted, not to any
>> conceivable other example you could have posted instead:
>
> You didn't answer the question:
The answer is irrelevant for the properties of your contrived example
I wrote about.
> Now suppose I have a different situation. I have Book and Book::InSeries
> objects as before, which should use this charge function:
>
> sub charge {
> my ($self, $count) = @_;
>
> my $price = $self->price;
> my $discount = $self->discount;
>
> $count * ($price - $price * $discount);
> }
>
> In the Book case, ->price and ->discount are properties; in the InSeries
> case, they are taken from the object's ->series property. I also have
> Bulk objects, which should use this charge function:
>
> sub charge {
> my ($self, $count) = @_;
>
> my $base = $self->price;
> my $discount = $self->discount;
> my $cutoff = $self->cutoff;
>
> my $price = $count > $cutoff ? $base * $discount : $base;
> $count * $price;
> }
>
> How would you implement these three classes? (I am genuinely interested
> in your answer to this question.)
And I'm not interested in createing a string of different
explanations trying to match the speed at which you can come up with
new contrived examples which have been 'constructed' such that the
previous explanation isn't applicable to them anymore because this is
just an endless chase of a goalpost which keeps being moved.
"Wer Ohren hat, der hoere. Wer nichts hoeren will der laessts
halt". Pax Hibiscus.
------------------------------
Date: Wed, 06 Mar 2013 21:02:42 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <87fw08i6ml.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> It is also not particularly 'structured around message passing'
In case this seems a little harsh to someone: Considering that this is
the 2nd "Let's move elsewhere!" posting, I'm assuming that this is
mainly an attempt at talking circles around me in order to obscure a
point instead of a discussion intended to clarify one. Since this
cannot possibly lead anywhere, I see no reason to engage in it.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3894
***************************************
