[32617] in Perl-Users-Digest
Perl-Users Digest, Issue: 3891 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Mar 4 09:09:21 2013
Date: Mon, 4 Mar 2013 06:09:05 -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 Mon, 4 Mar 2013 Volume: 11 Number: 3891
Today's topics:
Re: domain name ordering <jwkrahn@example.com>
Re: some random remarks about Moose::Manual::Concepts <marc.girod@gmail.com>
Re: some random remarks about Moose::Manual::Concepts <marc.girod@gmail.com>
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: Sun, 03 Mar 2013 18:13:49 -0800
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: domain name ordering
Message-Id: <yrTYs.29953$SE5.29788@newsfe28.iad>
Ivan Shmakov wrote:
> One more "domain name" problem: write an "inequality" predicate
> to compare domain names "right to left". IOW:
>
> my @ordered
> = qw (qux.example.net bar.example.org foo.bar.example.org foo.example.org);
>
> A trivial solution is to split /\./ each of the names, reverse
> the resulting lists, and then compare them elementwise, until
> either one of the lists ends (which is then the lesser one), or
> an inequality is found. Hence:
>
> sub list_cmp (&$$) {
> ## BTW, how do I imitate sort's own signature here?
> ## (i. e., make $cmp truly optional.)
You mean prototype, not signature.
$ perl -le'print prototype "CORE::sort"'
But sort doesn't have one so you can't imitate something that is not there.
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Sun, 3 Mar 2013 02:39:00 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <534646cb-f9bf-4ddb-81ad-52b4410fb363@g16g2000vbf.googlegroups.com>
Difficult to address 'random remarks'...
Especially I cannot do it in the context of Moose::Manual::Concepts
which could build up a consistent background: I never used Moose.
On Mar 2, 5:07=A0pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> the latter is just a
> way to accomplish the same as the former with more overhead.
Right, apart for making overriding possible.
This is once again a case of pay now, find why (maybe) later.
> The people who are usually credited with inventing 'modern
> OO' in form of Smalltalk didn't think of methods as 'subroutines
Didn't Larry Wall explain that Perl is a postmodern language?
> without adding intolerable overhead
> for 1980s hardware' aka 'C++' and all its conceptual descendants.
For C++ at least, the overhead is not in performance...
> The reason why I'm refering to this as 'a kludge' is that the sole
> purpose of an interface declaration is to inform the compiler that two
> things which aren't different in a certain aspect
Er... the class declaration would have been enough for that.
Java interfaces are a kludge because their single motivation
is to compensate for the lack of multiple inheritance of
behavior, by breaking the 'everything is a class' principle.
> I'm not usually interested in fighting my tools for
> ideological reasons such as the assumption that 'strong typing' would
> be a desirable property in its own right.
I have nothing against the way Perl works.
But I dislike this argument, maybe for 'ideological reasons'.
I take 'ideological' to be here only a derogative variant
of 'conceptual', 'abstract', 'paradigmatic'...
[ I usually reserve the word 'ideology' for justifications
of a de-facto power structure ]
Paradigms are set to validate conjectures which cannot
easily be proven, by building up a framework to produce
testable results, and address known issues.
Strong typing is one such paradigm. Even if it is not trendy
nowadays (and is remote to Perl), I believe the question of
its validity is still open.
This kind of paradigmatic thinking is imho useful, in the
same way as as esthetics or morals: it is too hard to fully
justify every one of one's moves.
In all respect for your competence, your openness, and your
bold critical spirit, Rainer.
Sorry for this out-of-scope discussion (mine, not yours).
Marc
------------------------------
Date: Sun, 3 Mar 2013 03:40:13 -0800 (PST)
From: Marc Girod <marc.girod@gmail.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <e1a274ea-34a4-40c7-ae4c-ab1617742818@cd3g2000vbb.googlegroups.com>
On Mar 3, 10:39=A0am, Marc Girod <marc.gi...@gmail.com> wrote:
> Right, apart for making overriding possible.
Sorry, I obviously meant overloading.
------------------------------
Date: Sun, 03 Mar 2013 21:33:36 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <87ppzgqibz.fsf@sapphire.mobileactivedefense.com>
Marc Girod <marc.girod@gmail.com> writes:
> Difficult to address 'random remarks'...
> Especially I cannot do it in the context of Moose::Manual::Concepts
> which could build up a consistent background: I never used Moose.
Well, neither did I. This was just an attempt at a criticism of some
parts of this 'introductory text' I'm especially at odds
with, motivated by the way in which this text markets[*] 'Moose' as
must-have solution to problems the author of Moose invented in order
to solve them (or whose importance he exaggerates greatly ---
preciously few of the constructors I've written so far didn't contain
anything except a 'bless' statement and if they did [almost], this was
usually because object initializion was supposed to be performed by
some overideable method and in these cases, the 'generic' constructor
was always inherited from a base class).
Since there are some point of 'general interest' (to me, at least) in
your text, I'll try to address them despite this is somewhat off topic
here.
[*] A very striking example of marketingspeak duplicity would be the
way this text refers to symbol table manipulations. If code doing this
is written by some class author in order to sovle a real problem, this
is called 'mucking about in the symbol table' or 'symbol table
hackery' but referred to as 'serious symbol table wizardry' when it is
done in order to provide a Moose-feature.
> On Mar 2, 5:07 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
[making all properties of an object available via 'accessor' methods']
>> the latter is just a way to accomplish the same as the former with
>> more overhead.
>
> Right, apart for making overriding possible.
If the property hadn't been exposed to begin with, overloading the
access method(s) in order to be able to change the implementation
wouldn't be necessary.
[...]
[C++ and "poor men's" message passing]
>> without adding intolerable overhead for 1980s hardware' aka 'C++'
>> and all its conceptual descendants.
>
> For C++ at least, the overhead is not in performance...
In C++, a 'virtual method' is one where a call is dispatched at
runtime by loading a function pointer from a certain slot of the
'virtual method table' associated with a particular class. That's
considerably less flexible than 'sending a named message with some
parameters' to an object which interprets this message by runtime
analysis: The compiler resolves the name to a vtable slot at
compilation time and all slots of all applicable vtables are also
populated at compilation time and remain constant at runtime. This
is a lot faster than any kind of 'name-based dispatching' with the
help of a runtime interpreter at the expense of tieing each method to
a class: There's no way for an unrelated object to act on the same
message,
>> The reason why I'm refering to this as 'a kludge' is that the sole
>> purpose of an interface declaration is to inform the compiler that two
>> things which aren't different in a certain aspect
>
> Er... the class declaration would have been enough for that.
> Java interfaces are a kludge because their single motivation
> is to compensate for the lack of multiple inheritance of
> behavior, by breaking the 'everything is a class' principle.
except when something like 'interface declarations' come into play:
This is a way to inform the compiler that unrelated classes do
actually have a common 'subset of message they can act on' aka
'compatible methods'. Something similar can be achieved with 'mutiple
inheritance' but only by introducing relatively awkward (IMO)
artificial abstractions. An example which came to my mind earlier
today: Both houses and cars have windows made of glass which can be
opened and closed. This would be a 'common interface' of these two
kinds of things. It could expressed with inheritance by defining
something like an 'intransparent thing with people in it who need/want
to look outside' class but (IMHO) a car is not something like a house
or vice versa, they just have some common characteristics, aka 'share
some set of messages/ methods'.
Also, the ancestors of a class are an implemenation detail of the
class (inheritance is about code reuse) and 'common behaviour of
different classes' shouldn't require them to share some part of their
implementations.
>
>> I'm not usually interested in fighting my tools for
>> ideological reasons such as the assumption that 'strong typing' would
>> be a desirable property in its own right.
>
> I have nothing against the way Perl works.
> But I dislike this argument, maybe for 'ideological reasons'.
> I take 'ideological' to be here only a derogative variant
> of 'conceptual', 'abstract', 'paradigmatic'...
An 'ideology' is a philosophical system sharing the trait that its
proponents consider it an absolute, universal truth which has to be
accepted uncritically if one doesn't want to forfeit one's 'immortal
soul' with usual (monotheistic) religious systems: It is based on a
set of 'core values' which are regarded as desirable because of
themselves, not because of something like 'practical usefulness', as
in
,----
| Type
|
| Hand-written parameter checking in your new() method and accessors.
|
| With Moose, you define types declaratively, and then use them by name
| with your attributes.
`----
The possibility that someone wouldn't want to check 'the types of
arguments passed to his subroutines' doesn't even enter the equation
here: The only two 'valid' options are 'write code whose sole purpose
is to compensate for what is regared as deficiency of the language' or
'use the wonderful "declarative system" which provides all this code
for free'. But - as I already wrote - I never do that in order to
force the invocation to fail when 'someone' performed it in a way I
didn't consider sensible, only if the subroutine should actually
perform different operations based on the kind of arguments which were
passed to it. This implies that any object which understands a certain
set of messages can be used by any code which is also aware of it.
------------------------------
Date: Mon, 4 Mar 2013 01:05:08 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <4j8d0a-dct1.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>
> [*] A very striking example of marketingspeak duplicity would be the
> way this text refers to symbol table manipulations. If code doing this
> is written by some class author in order to sovle a real problem, this
> is called 'mucking about in the symbol table' or 'symbol table
> hackery' but referred to as 'serious symbol table wizardry' when it is
> done in order to provide a Moose-feature.
You are being so overbearingly arrogant it makes my teeth hurt. The perl
symbol table is not a simple system. There are people in the world who
understand it better than you do (and better than I do, for that
matter). Saying 'this is difficult to do right, so you should leave it
to those who know what they're talking about to build tools with fewer
sharp edges' is not duplicity, it's common sense. (Even if you do
happen to be one of those people with a deep understanding of the symbol
table, the Moose documentation is not addressed to you specifically, but
to Perl programmers in general.)
(And yes, I have built my own class-construction system (two, actually,
though one of them never really got to the point of being useful), and
one of the things on my todo list is to port it to Moose, because that's
the sensible thing to do.)
> Marc Girod <marc.girod@gmail.com> writes:
> > On Mar 2, 5:07 pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
>
> [making all properties of an object available via 'accessor' methods']
>
> >> the latter is just a way to accomplish the same as the former with
> >> more overhead.
> >
> > Right, apart for making overriding possible.
>
> If the property hadn't been exposed to begin with, overloading the
> access method(s) in order to be able to change the implementation
> wouldn't be necessary.
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'), so that subclasses can change the way they work.
Every time you write $self->{foo} you are requiring that every subclass
must use a hashref-based object containing a 'foo' key with the
semantics you expect. If instead you use $self->foo even internally, a
subclass can produce its value for that attribute in any way it chooses.
Just because a method exists doesn't mean it's OK for random external
code to call it. That's a question for the documentation.
> [C++ and "poor men's" message passing]
>
> >> without adding intolerable overhead for 1980s hardware' aka 'C++'
> >> and all its conceptual descendants.
> >
> > For C++ at least, the overhead is not in performance...
>
> In C++, a 'virtual method' is one where a call is dispatched at
> runtime by loading a function pointer from a certain slot of the
> 'virtual method table' associated with a particular class. That's
> considerably less flexible than 'sending a named message with some
> parameters' to an object which interprets this message by runtime
> analysis:
Yes, C++'s object model is junk. I think we all know that, and I'm not
sure what relevance it has to either Perl or Moose. (In case you were
under any misconception, Moose is not trying to be 'C++-in-Perl', it's
trying to be 'CLOS-in-Perl', approximately.)
> >> The reason why I'm refering to this as 'a kludge' is that the sole
> >> purpose of an interface declaration is to inform the compiler that two
> >> things which aren't different in a certain aspect
> >
> > Er... the class declaration would have been enough for that.
> > Java interfaces are a kludge because their single motivation
> > is to compensate for the lack of multiple inheritance of
> > behavior, by breaking the 'everything is a class' principle.
>
> except when something like 'interface declarations' come into play:
> This is a way to inform the compiler that unrelated classes do
> actually have a common 'subset of message they can act on' aka
> 'compatible methods'. Something similar can be achieved with 'mutiple
> inheritance' but only by introducing relatively awkward (IMO)
> artificial abstractions. An example which came to my mind earlier
> today: Both houses and cars have windows made of glass which can be
> opened and closed. This would be a 'common interface' of these two
> kinds of things. It could expressed with inheritance by defining
> something like an 'intransparent thing with people in it who need/want
> to look outside' class but (IMHO) a car is not something like a house
> or vice versa, they just have some common characteristics, aka 'share
> some set of messages/ methods'.
You are basically talking about the difference between what ObjC (and
therefore I assume Smalltalk?) calls 'formal' and 'informal protocols',
and saying that you prefer informal protocols. I must say I entirely
disagree with you here, because of the Tree->bark vs Dog->bark problem;
though in practice a lot of code uses informal protocols, so presumably
this doesn't come up as often as I might fear. (Of the languages I know,
Python and Ruby use them extensively under the name of 'duck typing';
ObjC uses them a lot more than I like; most of the small subset of Perl
code which tries to do useful things with arbitrary objects does so by
using ->can, which is just duck typing.)
> Also, the ancestors of a class are an implemenation detail of the
> class (inheritance is about code reuse) and 'common behaviour of
> different classes' shouldn't require them to share some part of their
> implementations.
Yes. This is why I would prefer classes (or, actually, objects) to
declare their conformance or not to something equivalent to a formal
protocol as the only externally-visible way of asking 'is this a duck?'.
Java interfaces are identical to formal protocols; the Perl ->DOES
method is intended to implement them, though in practice it is almost
never used.
In my ideal object system there would be no classes; instead every
object would specify that it conforms to some list of protocols, and
would acquire method implementations from some list of roles, where some
of those roles might require the object implement a given protocol
before they can be included. It would also include something along the
lines of COM's QueryInterface, preferably invoked implicitly to avoid
the ridiculous verbosity of typical COM systems, so that an EntishHound
object can be treated as a Tree and get an appropriate ->bark for that
use, and then be treated as a Dog and get a different appropriate ->bark
(C< say "woofrum woofoom" >) for that use.
> >> I'm not usually interested in fighting my tools for
> >> ideological reasons such as the assumption that 'strong typing' would
> >> be a desirable property in its own right.
> >
> > I have nothing against the way Perl works.
> > But I dislike this argument, maybe for 'ideological reasons'.
> > I take 'ideological' to be here only a derogative variant
> > of 'conceptual', 'abstract', 'paradigmatic'...
>
> An 'ideology' is a philosophical system sharing the trait that its
> proponents consider it an absolute, universal truth which has to be
> accepted uncritically if one doesn't want to forfeit one's 'immortal
> soul' with usual (monotheistic) religious systems: It is based on a
> set of 'core values' which are regarded as desirable because of
> themselves, not because of something like 'practical usefulness',
The word you are looking for is 'dogma'. 'Ideology' properly means
something rather different, except that, as with many philosophical
terms, certain 20thC political groups have twisted it to the point where
it conveys very little beyond 'this is BAD'.
> ,----
> | Type
> |
> | Hand-written parameter checking in your new() method and accessors.
> |
> | With Moose, you define types declaratively, and then use them by name
> | with your attributes.
> `----
>
> The possibility that someone wouldn't want to check 'the types of
> arguments passed to his subroutines' doesn't even enter the equation
> here: The only two 'valid' options are 'write code whose sole purpose
> is to compensate for what is regared as deficiency of the language' or
> 'use the wonderful "declarative system" which provides all this code
> for free'.
If you had actually read the damn documentation instead of jumping on
your soapbox to proclaim Stevan Little as the Antichrist you would have
found that the Moose type system is entirely optional. I've written a
fair amount of code using (systems which use) Moose, and I've not used
it once. (Admittedly, this may be a flaw in my code, but if it is it's
one I am currently choosing to ignore.)
> But - as I already wrote - I never do that in order to
> force the invocation to fail when 'someone' performed it in a way I
> didn't consider sensible, only if the subroutine should actually
> perform different operations based on the kind of arguments which were
> passed to it.
The latter case is where the type system is useful. It's also useful for
catching errors early: if someone passes an X object when they should
have passed a Y, debugging the resulting error can be much harder than
if the method that was originally passed the wrong object had thrown an
error immediately.
> This implies that any object which understands a certain
> set of messages can be used by any code which is also aware of it.
This constraint ('Any object which understands a certain set of
messages') can be easily expressed in the Moose type-constraint system,
should you desire to do so, either by requiring a particular role
(formal protocol) or by requiring a specified list of methods (informal
protocol).
A detailed and somewhat incensed criticism based on a near-complete lack
of understanding of said system is very unlikely to have any useful
bearing on reality. I get the impression you are not someone who has
very much time for that sort of cant, so I'm a little puzzled as to why
you keep producing it.
Ben
------------------------------
Date: Mon, 04 Mar 2013 10:57:12 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <878v63l9fb.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> [*] A very striking example of marketingspeak duplicity would be the
>> way this text refers to symbol table manipulations. If code doing this
>> is written by some class author in order to sovle a real problem, this
>> is called 'mucking about in the symbol table' or 'symbol table
>> hackery' but referred to as 'serious symbol table wizardry' when it is
>> done in order to provide a Moose-feature.
>
> You are being so overbearingly arrogant it makes my teeth hurt.
> The perl symbol table is not a simple system. There are people in
> the world who understand it better than you do
You have absolutely no idea of my level of 'understanding' of anything
and this 'en minature' rant has no relation whatsoever to the text I
wrote you happened to attach it to.
[...]
>> [making all properties of an object available via 'accessor' methods']
>>
>> >> the latter is just a way to accomplish the same as the former with
>> >> more overhead.
>> >
>> > Right, apart for making overriding possible.
>>
>> If the property hadn't been exposed to begin with, overloading the
>> access method(s) in order to be able to change the implementation
>> wouldn't be necessary.
>
> 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'), so that subclasses can change the way they
> work. Every time you write $self->{foo} you are requiring that every
> subclass must use a hashref-based object containing a 'foo' key with the
> semantics you expect.
As I wrote in my original text: Attributes shouldn't be exposed at
all. A class should provide methods with some kind of 'useful behaviour',
both for subclassed and class users and how this behavior is actually
implemented shouldn't be anybody's business. And I meant that. That's
called 'encapsulation' and it is generally a good thing because it
decouples the interface from the implementation.
I was planning to write a more detailed reply but the lack of
understanding you've shown here, both about basic OO concepts and the
two postings I wrote, has made me lose any interest in that.
------------------------------
Date: Mon, 04 Mar 2013 12:11:26 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <87vc971i1d.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
>>
>> [*] A very striking example of marketingspeak duplicity would be the
>> way this text refers to symbol table manipulations. If code doing this
>> is written by some class author in order to sovle a real problem, this
>> is called 'mucking about in the symbol table' or 'symbol table
>> hackery' but referred to as 'serious symbol table wizardry' when it is
>> done in order to provide a Moose-feature.
>
> You are being so overbearingly arrogant it makes my teeth hurt.
> The perl symbol table is not a simple system. There are people in
> the world who understand it better than you do
You have absolutely no idea of my level of 'understanding' of anything
and this 'en minature' rant has no relation whatsoever to the text I
wrote you happened to attach it to.
[...]
>> [making all properties of an object available via 'accessor' methods']
>>
>> >> the latter is just a way to accomplish the same as the former with
>> >> more overhead.
>> >
>> > Right, apart for making overriding possible.
>>
>> If the property hadn't been exposed to begin with, overloading the
>> access method(s) in order to be able to change the implementation
>> wouldn't be necessary.
>
> 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'), so that subclasses can change the way they
> work. Every time you write $self->{foo} you are requiring that every
> subclass must use a hashref-based object containing a 'foo' key with the
> semantics you expect.
As I wrote in my original text: In general, attributes shouldn't be
exposed at all. A class should provide methods with some kind of
'useful behaviour', both for subclasses and class users and how this
behavior is actually implemented shouldn't be anybody's business. And
I meant that.
[...]
>> [C++ and "poor men's" message passing]
>>
>> >> without adding intolerable overhead for 1980s hardware' aka 'C++'
>> >> and all its conceptual descendants.
>> >
>> > For C++ at least, the overhead is not in performance...
>>
>> In C++, a 'virtual method' is one where a call is dispatched at
>> runtime by loading a function pointer from a certain slot of the
>> 'virtual method table' associated with a particular class. That's
>> considerably less flexible than 'sending a named message with some
>> parameters' to an object which interprets this message by runtime
>> analysis:
>
> Yes, C++'s object model is junk. I think we all know that, and I'm not
> sure what relevance it has to either Perl or Moose. (In case you were
> under any misconception, Moose is not trying to be 'C++-in-Perl', it's
> trying to be 'CLOS-in-Perl', approximately.)
My general impression would be that it is trying to be 'Java in Perl'
(that would be 'C++ for dummies'), with a couple of the more weird
CLOS features added in because the Moose author enjoyed being the
Seriously Supercool Symbol Table Wizard[tm]. But that's really besides
the point when discussing message passing semantics for inter-object
communication.
>> >> The reason why I'm refering to this as 'a kludge' is that the sole
>> >> purpose of an interface declaration is to inform the compiler that two
>> >> things which aren't different in a certain aspect
>> >
>> > Er... the class declaration would have been enough for that.
>> > Java interfaces are a kludge because their single motivation
>> > is to compensate for the lack of multiple inheritance of
>> > behavior, by breaking the 'everything is a class' principle.
>>
>> except when something like 'interface declarations' come into play:
>> This is a way to inform the compiler that unrelated classes do
>> actually have a common 'subset of message they can act on' aka
>> 'compatible methods'. Something similar can be achieved with 'mutiple
>> inheritance' but only by introducing relatively awkward (IMO)
>> artificial abstractions. An example which came to my mind earlier
>> today: Both houses and cars have windows made of glass which can be
>> opened and closed. This would be a 'common interface' of these two
>> kinds of things. It could expressed with inheritance by defining
>> something like an 'intransparent thing with people in it who need/want
>> to look outside' class but (IMHO) a car is not something like a house
>> or vice versa, they just have some common characteristics, aka 'share
>> some set of messages/ methods'.
>
> You are basically talking about the difference between what ObjC (and
> therefore I assume Smalltalk?) calls 'formal' and 'informal protocols',
> and saying that you prefer informal protocols.
I have no idea what 'Objective-C' calls a 'formal' or an 'informal'
protocol, consequently, I cannot possibly have written anything about
that. What I was writing about was the ability to send arbitrary
messages to object instances which enables unrelated objects to
provide compatible interfaces if so desired. And this really means
'unrelated objects', not
[...]
>> Also, the ancestors of a class are an implemenation detail of the
>> class (inheritance is about code reuse) and 'common behaviour of
>> different classes' shouldn't require them to share some part of their
>> implementations.
>
> Yes. This is why I would prefer classes (or, actually, objects) to
> declare their conformance or not to something equivalent to a formal
> protocol as the only externally-visible way of asking 'is this a duck?'.
> Java interfaces are identical to formal protocols;
objects which have an indirect relation to each other because somebody
defined a 'meta-class' (the term 'meta' is here used with a different
meaning than it is usually used for OOP) and the objects are both
'meta-instances' of the 'meta-class'. That's nothing but an
inheritance-relationship with an additional level of indirection
(losely spoken) born out of the necessity to be more flexible in this
respect than 'James Gosling originally believed to be necessary' (also
losely spoken).
Asking an object "Are you a duck?"[*], to stay with this example, is
something which shouldn't ever be necessary, and the only sensible
answer would be "Why do you care?" (I tend to answer the ritual 'Where
are you from?' question in this way precisely because my
'implementation' shouldn't be anybody's business). The object is used
in a certain context and either, it provides 'suitable behaviour' aka
'reacts in a sensible way to certain messages sent to it', than, the
final result will hopefully be something somebody considers useful and
otherwise, it will be a (usually fatal) runtime error.
[*] Assuming the answer was "I'm a value beef meal", what precisely
would that mean?
[...]
> In my ideal object system there would be no classes; instead every
> object would specify that it conforms to some list of protocols, and
> would acquire method implementations from some list of roles, where some
> of those roles might require the object implement a given protocol
> before they can be included. It would also include something along the
> lines of COM's QueryInterface, preferably invoked implicitly to avoid
> the ridiculous verbosity of typical COM systems, so that an EntishHound
> object can be treated as a Tree and get an appropriate ->bark for that
> use, and then be treated as a Dog and get a different appropriate ->bark
> (C< say "woofrum woofoom" >) for that use.
This looks like a somewhat informal description of a different
'general bureacratic schema to classify and organize them all' and one
which requires even more 'boilerplate declarations' than 'formally
defined' class hierarchies. I have no experience with that but
generally, the same objections: This complication isn't necessary and
I'm strongly inclined to suspect that it is rather psychologically
than technically motivated. Someone's fear of the unknown is supposed
to be dealt with by 'controlling everything upfront' (Lest the
nameless chaos will eat us all, mark my words!).
That's not how Perl-OO works and I'm quite happy with that.
>
>> >> I'm not usually interested in fighting my tools for
>> >> ideological reasons such as the assumption that 'strong typing' would
>> >> be a desirable property in its own right.
>> >
>> > I have nothing against the way Perl works.
>> > But I dislike this argument, maybe for 'ideological reasons'.
>> > I take 'ideological' to be here only a derogative variant
>> > of 'conceptual', 'abstract', 'paradigmatic'...
>>
>> An 'ideology' is a philosophical system sharing the trait that its
>> proponents consider it an absolute, universal truth which has to be
>> accepted uncritically if one doesn't want to forfeit one's 'immortal
>> soul' with usual (monotheistic) religious systems: It is based on a
>> set of 'core values' which are regarded as desirable because of
>> themselves, not because of something like 'practical usefulness',
>
> The word you are looking for is 'dogma'.
'Dogma' is a religious term. AFAIK, it's the Roman-Catholic equivalent
of an axiom (and the implication that theology and mathematics are
closely related at a 'structural' level is absolutely intentional).
> 'Ideology' properly means something rather different, except that,
> as with many philosophical terms, certain 20thC political groups
> have twisted it to the point where it conveys very little beyond
> 'this is BAD'.
I've used it in the way it is usually used in contemporary German, eg
Marxism/ Communism would be called 'an ideology' (as would be
[Jehova!], fascism). The way 'strong typing' is usually advocated has
certain similarities to that, eg, the notion that people who disagree
with 'the idea' are not simply people with a different opinion but
'beings of lesser value' (as in 'You are being so overbearingly
arrogant it makes my teeth hurt.'). So far, the results haven't been
equally murderous but considering that people have already demanded
execution of 'global warming sceptics', this is probably rather a
problem of not being capable of physically exterminating the
unbelievers and not of not desiring to do so.
>> ,----
>> | Type
>> |
>> | Hand-written parameter checking in your new() method and accessors.
>> |
>> | With Moose, you define types declaratively, and then use them by name
>> | with your attributes.
>> `----
>>
>> The possibility that someone wouldn't want to check 'the types of
>> arguments passed to his subroutines' doesn't even enter the equation
>> here: The only two 'valid' options are 'write code whose sole purpose
>> is to compensate for what is regared as deficiency of the language' or
>> 'use the wonderful "declarative system" which provides all this code
>> for free'.
>
> If you had actually read the damn documentation instead of jumping on
> your soapbox to proclaim Stevan Little as the Antichrist
I haven't proclaimed anyone as anything, despite I've been so
overbearingly arrogant to use certain quotes from a text I read which
happened to cast a somewhat-less-than-favorable light onto the people
who wrote the text I was referring to. I didn't refer to some other
text you seem to be referring to and if the 'concepts' text I did read
doesn't describe the thing it is supposed to describe correctly, as
you're suggesting, that would be another problem with it.
[...]
>> But - as I already wrote - I never do that in order to
>> force the invocation to fail when 'someone' performed it in a way I
>> didn't consider sensible, only if the subroutine should actually
>> perform different operations based on the kind of arguments which were
>> passed to it.
>
> The latter case is where the type system is useful. It's also useful for
> catching errors early: if someone passes an X object when they
> should
"... just use Ada, dammit, and stop being so arrogant to assume they
had the right to a different opinion !!!"
Strong-typing advocacy 101.
[...]
>> This implies that any object which understands a certain
>> set of messages can be used by any code which is also aware of it.
>
> This constraint ('Any object which understands a certain set of
> messages') can be easily expressed in the Moose type-constraint system,
> should you desire to do so,
But I don't desire to do so because I don't buy into the theory/
ideology/ dogmatology/ you-name-it that 'strong typing' is the only or
the only True[tm] way to deal with certain aspects of 'programming
languages and environments'. That's something certain people have been
at loggerheads about since the 1970s (probably earlier) and
specifically, something some people from Europe considered to be
absolutely essential from a mostly theoretical point of view while
'some other people' from the USA built practically useful, complex
computer systems without it (or mostly without it). This constitutes
empirical evidence that it isn't really essential and hence, all the
vitriol, since humans never change their opinons on anything just
because they are/ were demonstrably wrong.
My opinion on that would be 'Could we perhaps but the matter to a rest
and focus on more practical stuff' (Did I tell you of a really great,
'weakly typed' OO system I've been using productively to solve all
kinds of 'real-world' problems for more than 15 years? No antlers
attached :-).
------------------------------
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 3891
***************************************
