[32621] in Perl-Users-Digest
Perl-Users Digest, Issue: 3895 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 7 11:09:21 2013
Date: Thu, 7 Mar 2013 08: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 Thu, 7 Mar 2013 Volume: 11 Number: 3895
Today's topics:
Re: getting perl and php to talk to each other <cal@example.invalid>
Re: getting perl and php to talk to each other <cal@example.invalid>
Re: getting perl and php to talk to each other <ben@morrow.me.uk>
Re: getting perl and php to talk to each other <cal@example.invalid>
Re: getting perl and php to talk to each other <swisscheese@cfl.rr.com>
Re: getting perl and php to talk to each other <jstucklex@attglobal.net>
Re: getting perl and php to talk to each other <jstucklex@attglobal.net>
Re: getting perl and php to talk to each other <ben@morrow.me.uk>
Re: getting perl and php to talk to each other <ben@morrow.me.uk>
message forwarding in perl <rweikusat@mssgmbh.com>
moving class indepdent methods out of class definitions <rweikusat@mssgmbh.com>
Re: some random remarks about Moose::Manual::Concepts <ben@morrow.me.uk>
Re: some random remarks about Moose::Manual::Concepts <ben@morrow.me.uk>
Re: some random remarks about Moose::Manual::Concepts <stevem_@nogood.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 06 Mar 2013 22:37:39 -0800
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: getting perl and php to talk to each other
Message-Id: <KZ-dnfo_fuUuqKXMnZ2dnUVZ_s6dnZ2d@supernews.com>
On 03/05/2013 05:08 PM, Jerry Stuckle wrote:
> On 3/5/2013 6:59 PM, Ben Morrow wrote:
>>>> Why on Earth would you want to do that? Seriously, I can't think of any
>>>> situation where mixing PHP and Perl is easier than just writing in Perl
>>>> in the first place.
>>>
>>> Other people would say the same about writing PHP instead of a mix.
>>
>> Yes, of course.
>>
>
> A long shot - maybe you have a package in one language you need to feed
> input to. But that input must first be processed by a package in the
> other language. Rather than rewrite everything, merge them together.
What I wanted to do that this article had mentioned was to be able to
call perl reliably either from php or from a bash script that
comprehends it all.
>
> Or, perhaps you need to build the data preprocessor, and aren't familiar
> with the language the package is written in.
I've chosen this rather arbitrary task just to see what I can do with
this syntax which is new to me, php, as opposed to what a person can do
with, perl, which I have previously used to give me a webpage.
>
> I agree it would be quite rare, but it's about the only reason I could
> think of people would need both languages. I'm sure there are more,
> though.
Can I use perl regex's or do I have to learn a whole 'nother idea of
what that is?
>
>>> However, there can be value in two programming languages in the same
>>> program. Just consider what kinds of data you can pass via the command
>>> line and what kinds you cannot pass that way (yes, there are text files,
>>> named pipes, and other equally ugly workarounds).
>>
>> The methods used by PHP::Interpreter are not really any less ugly. Until
>> you get to the point of being able to run the two languages on the same
>> VM with properly interworking data structures (such as Parrot is trying
>> to achieve, for instance) I don't see much point stuffing the two
>> languages into the same process and then just passing strings to eval
>> back and forth.
>>
>
> I doubt that they'll ever have internetworking data structures, though.
> Just not a need for it.
No, nothing like that complex.
[snip]
[OT]
> I wouldn't have bothered looking up when a Perl module was shipped, either.
>
> BTW - comp.lang.perl.misc added back since this is about both languages.
>
I'm not thrilled with being OT again, but I just can't get
PHP::Interpreter to install and don't know exactly why. I don't like to
be OT, but something that seems to work for others isn't for me now, and
it's not at the level of scripting languages.
I can ask very-flawed specific questions but need to wonder aloud why
php-config doesn't work, why files that are supposed to be there aren't,
and how I troubleshoot the basic function of it before I actually get
this topic off the ground.
What exactly do I have to do at this point to get a php-config that
works as far as PHP::Interpreter is concerned?
I've tried ten things that don't work.
--
Cal
------------------------------
Date: Wed, 06 Mar 2013 22:53:01 -0800
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: getting perl and php to talk to each other
Message-Id: <kqKdnfWb5I3RpKXMnZ2dnUVZ_h-dnZ2d@supernews.com>
On 03/05/2013 02:06 PM, Ben Morrow wrote:
>
> Quoth Cal Dershowitz <cal@example.invalid>:
>> [x-posted to clp.misc]
> [...]
>>
>> This article has me convinced that I want perl and php able to deal with
>> each other:
>>
>> http://www.linuxjournal.com/article/9282?page=0,1
>
> Why on Earth would you want to do that? Seriously, I can't think of any
> situation where mixing PHP and Perl is easier than just writing in Perl
> in the first place.
>
> Note that the Perl in that article (or at least, the first page, which
> was all I read) is pretty bad:
>
> - use of global filehandles, unnecessary since 2000,
> - use of Thread.pm, deprecated since 2002,
> - use of threads at all for such a trivial problem,
> - using rindex and substr rather than pattern matching,
> - using backticks instead of system(),
> - using PHP to talk to a database, when Perl's DBI module is
> considerably better than PHP's rather random database functions.
>
> I don't know PHP well enough to comment on it, but I wouldn't be
> surprised if the PHP code was just as bad (for instance, I understand
> PHP has a saner database interface these days; I don't know if it
> existed in 2007, though).
>
>> so far so good, and then this thing which I've seen in the literature:
>>
>> using php_config 'php-config'
>> Can't exec "php-config": No such file or directory at Makefile.PL line 55.
>> Failed to find the 'php-config' executable. Make sure you have PHP and
>> PHP sources installed, and that 'php-config' is in PATH. at Makefile.PL
>> line 55.
>> ...
>>
>> bla bla bla do not pass Go. Right now I have a default installation.
>>
>> Simple question: What types of things can I get configured with
>> php-config? envelope data available? ftp data?
>
> php-config is a program installed with php, which tells other programs
> how php was installed. For instance, on my system
>
> ~% php-config --libs
> -lcrypt -lcrypt -lpcre -lm -lxml2 -lz -liconv -lm -lcrypt -lcrypt
> ~% php-config --includes
> -I/usr/local/include/php -I/usr/local/include/php/main
> -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend
> -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib
> ~%
>
> and so on. If you've installed php properly (including any required
> development packages, if you're using a package system), you should have
> a php-config executable somewhere. Make sure it's in your PATH before
> running Makefile.PL.
Struggling.
$ php-config --libs
No command 'php-config' found, did you mean:
Command 'pdp-config' from package 'pd-pdp' (universe)
Command 'php-config5' from package 'php5-dev' (main)
php-config: command not found
$
--
Cal
------------------------------
Date: Thu, 7 Mar 2013 06:57:35 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: getting perl and php to talk to each other
Message-Id: <vbql0a-44v2.ln1@anubis.morrow.me.uk>
Quoth Cal Dershowitz <cal@example.invalid>:
>
> I've chosen this rather arbitrary task just to see what I can do with
> this syntax which is new to me, php, as opposed to what a person can do
> with, perl, which I have previously used to give me a webpage.
Cal, please, try to learn one language properly before wildly
introducing more languages to the equation. It *really* isn't going to
help.
> What exactly do I have to do at this point to get a php-config that
> works as far as PHP::Interpreter is concerned?
I have already answered that question.
Ben
------------------------------
Date: Thu, 07 Mar 2013 00:52:58 -0800
From: Cal Dershowitz <cal@example.invalid>
Subject: Re: getting perl and php to talk to each other
Message-Id: <0a2dnd985Zb0yKXMnZ2dnUVZ_rWdnZ2d@supernews.com>
On 03/06/2013 10:57 PM, Ben Morrow wrote:
>
> Quoth Cal Dershowitz <cal@example.invalid>:
>>
>> I've chosen this rather arbitrary task just to see what I can do with
>> this syntax which is new to me, php, as opposed to what a person can do
>> with, perl, which I have previously used to give me a webpage.
>
> Cal, please, try to learn one language properly before wildly
> introducing more languages to the equation. It *really* isn't going to
> help.
Help what? Are you certain that it's completely impossible that a file
could go missing from me that I would need to do this, and that there
would be every reason in this fascist world world to keep me from
getting a decent web capability?
I don't seem to be loading up facebook.ben.pl very often.
>
>> What exactly do I have to do at this point to get a php-config that
>> works as far as PHP::Interpreter is concerned?
>
> I have already answered that question.
>
> Ben
>
Can I bother you to repeat it?
--
Cal
------------------------------
Date: Thu, 07 Mar 2013 06:28:33 -0500
From: SwissCheese <swisscheese@cfl.rr.com>
Subject: Re: getting perl and php to talk to each other
Message-Id: <kh9tib$9k9$1@dont-email.me>
On 03/07/2013 01:53 AM, Cal Dershowitz wrote:
> On 03/05/2013 02:06 PM, Ben Morrow wrote:
>>
>> Quoth Cal Dershowitz <cal@example.invalid>:
>>> [x-posted to clp.misc]
>> [...]
>>>
>>> This article has me convinced that I want perl and php able to deal with
>>> each other:
>>>
>>> http://www.linuxjournal.com/article/9282?page=0,1
>>
>> Why on Earth would you want to do that? Seriously, I can't think of any
>> situation where mixing PHP and Perl is easier than just writing in Perl
>> in the first place.
>>
>> Note that the Perl in that article (or at least, the first page, which
>> was all I read) is pretty bad:
>>
>> - use of global filehandles, unnecessary since 2000,
>> - use of Thread.pm, deprecated since 2002,
>> - use of threads at all for such a trivial problem,
>> - using rindex and substr rather than pattern matching,
>> - using backticks instead of system(),
>> - using PHP to talk to a database, when Perl's DBI module is
>> considerably better than PHP's rather random database functions.
>>
>> I don't know PHP well enough to comment on it, but I wouldn't be
>> surprised if the PHP code was just as bad (for instance, I understand
>> PHP has a saner database interface these days; I don't know if it
>> existed in 2007, though).
>>
>>> so far so good, and then this thing which I've seen in the literature:
>>>
>>> using php_config 'php-config'
>>> Can't exec "php-config": No such file or directory at Makefile.PL
>>> line 55.
>>> Failed to find the 'php-config' executable. Make sure you have PHP and
>>> PHP sources installed, and that 'php-config' is in PATH. at Makefile.PL
>>> line 55.
>>> ...
>>>
>>> bla bla bla do not pass Go. Right now I have a default installation.
>>>
>>> Simple question: What types of things can I get configured with
>>> php-config? envelope data available? ftp data?
>>
>> php-config is a program installed with php, which tells other programs
>> how php was installed. For instance, on my system
>>
>> ~% php-config --libs
>> -lcrypt -lcrypt -lpcre -lm -lxml2 -lz -liconv -lm -lcrypt -lcrypt
>> ~% php-config --includes
>> -I/usr/local/include/php -I/usr/local/include/php/main
>> -I/usr/local/include/php/TSRM -I/usr/local/include/php/Zend
>> -I/usr/local/include/php/ext -I/usr/local/include/php/ext/date/lib
>> ~%
>>
>> and so on. If you've installed php properly (including any required
>> development packages, if you're using a package system), you should have
>> a php-config executable somewhere. Make sure it's in your PATH before
>> running Makefile.PL.
>
> Struggling.
>
> $ php-config --libs
> No command 'php-config' found, did you mean:
> Command 'pdp-config' from package 'pd-pdp' (universe)
> Command 'php-config5' from package 'php5-dev' (main)
> php-config: command not found
> $
Try php-config5 as php-config is a link to php-config5. Here they
both reside in /usr/bin. If you are missing php-config link (it appears
so) then create it.
--
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-
------------------------------
Date: Thu, 07 Mar 2013 08:14:28 -0500
From: Jerry Stuckle <jstucklex@attglobal.net>
Subject: Re: getting perl and php to talk to each other
Message-Id: <kha3p0$9l5$1@dont-email.me>
On 3/7/2013 1:37 AM, Cal Dershowitz wrote:
> On 03/05/2013 05:08 PM, Jerry Stuckle wrote:
>> On 3/5/2013 6:59 PM, Ben Morrow wrote:
>
<snip>
> What I wanted to do that this article had mentioned was to be able to
> call perl reliably either from php or from a bash script that
> comprehends it all.
To what purpose?
<snip>
> I've chosen this rather arbitrary task just to see what I can do with
> this syntax which is new to me, php, as opposed to what a person can do
> with, perl, which I have previously used to give me a webpage.
To what purpose?
>>
>> I agree it would be quite rare, but it's about the only reason I could
>> think of people would need both languages. I'm sure there are more,
>> though.
>
> Can I use perl regex's or do I have to learn a whole 'nother idea of
> what that is?
If you're writing in PHP, you learn PHP's way of doing things. It also
has regex's (which are pretty close to Perl's).
<snip>
> I'm not thrilled with being OT again, but I just can't get
> PHP::Interpreter to install and don't know exactly why. I don't like to
> be OT, but something that seems to work for others isn't for me now, and
> it's not at the level of scripting languages.
>
Most people don't try to mix languages like you are. It overly
complicates things.
> I can ask very-flawed specific questions but need to wonder aloud why
> php-config doesn't work, why files that are supposed to be there aren't,
> and how I troubleshoot the basic function of it before I actually get
> this topic off the ground.
>
> What exactly do I have to do at this point to get a php-config that
> works as far as PHP::Interpreter is concerned?
>
> I've tried ten things that don't work.
So, how did you install PHP?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
------------------------------
Date: Thu, 07 Mar 2013 08:17:32 -0500
From: Jerry Stuckle <jstucklex@attglobal.net>
Subject: Re: getting perl and php to talk to each other
Message-Id: <kha3uo$amk$1@dont-email.me>
On 3/7/2013 3:52 AM, Cal Dershowitz wrote:
> On 03/06/2013 10:57 PM, Ben Morrow wrote:
>>
>> Quoth Cal Dershowitz <cal@example.invalid>:
>>>
>>> I've chosen this rather arbitrary task just to see what I can do with
>>> this syntax which is new to me, php, as opposed to what a person can do
>>> with, perl, which I have previously used to give me a webpage.
>>
>> Cal, please, try to learn one language properly before wildly
>> introducing more languages to the equation. It *really* isn't going to
>> help.
>
> Help what? Are you certain that it's completely impossible that a file
> could go missing from me that I would need to do this, and that there
> would be every reason in this fascist world world to keep me from
> getting a decent web capability?
>
There are hundreds of millions of web sites which have "decent web
capabilities" but don't try to mix languages. I agree with Ben - learn
one language first.
And if you want help, I *highly* suggest you change your attitude.
Calling people facists does not endear ANYONE.
> I don't seem to be loading up facebook.ben.pl very often.
>>
>>> What exactly do I have to do at this point to get a php-config that
>>> works as far as PHP::Interpreter is concerned?
>>
>> I have already answered that question.
>>
>> Ben
>>
>
> Can I bother you to repeat it?
Can you bother to go back and read the earlier messages in this thread?
I've tried to help, but you are *quickly* wearing my patience with your
attitude.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
------------------------------
Date: Thu, 7 Mar 2013 14:25:04 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: getting perl and php to talk to each other
Message-Id: <0jkm0a-td13.ln1@anubis.morrow.me.uk>
Quoth Cal Dershowitz <cal@example.invalid>:
> On 03/06/2013 10:57 PM, Ben Morrow wrote:
> > Quoth Cal Dershowitz <cal@example.invalid>:
> >>
> >> I've chosen this rather arbitrary task just to see what I can do with
> >> this syntax which is new to me, php, as opposed to what a person can do
> >> with, perl, which I have previously used to give me a webpage.
> >
> > Cal, please, try to learn one language properly before wildly
> > introducing more languages to the equation. It *really* isn't going to
> > help.
>
> Help what? Are you certain that it's completely impossible that a file
> could go missing from me that I would need to do this, and that there
> would be every reason in this fascist world world to keep me from
> getting a decent web capability?
I am quite certain that whatever it is you are trying to accomplish, you
can do it more easily in either Perl or PHP alone than in both combined.
You seem to keep losing files. You should consider taking backups, or
using a version control system.
> I don't seem to be loading up facebook.ben.pl very often.
That makes no sense. If you want help, you should start by making at
least a token effort to make sense.
Ben
------------------------------
Date: Thu, 7 Mar 2013 14:33:17 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: getting perl and php to talk to each other
Message-Id: <d2lm0a-td13.ln1@anubis.morrow.me.uk>
Quoth swisscheese@cfl.rr.com:
> On 03/07/2013 01:53 AM, Cal Dershowitz wrote:
> >
> > Struggling.
> >
> > $ php-config --libs
> > No command 'php-config' found, did you mean:
> > Command 'pdp-config' from package 'pd-pdp' (universe)
> > Command 'php-config5' from package 'php5-dev' (main)
> > php-config: command not found
> > $
>
> Try php-config5 as php-config is a link to php-config5. Here they
> both reside in /usr/bin. If you are missing php-config link (it appears
> so) then create it.
Installing the php-dev package should have created this link:
http://xrl.us/bomxwq .
Ben
------------------------------
Date: Thu, 07 Mar 2013 15:42:19 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: message forwarding in perl
Message-Id: <87ip539pyc.fsf@sapphire.mobileactivedefense.com>
Another trivial thing I'm actually using: Can be implemented via
AUTOLOAD. The fact that UNIVERSAL->can and AUTOLOAD don't play nice
with each other is actually documented. Again, one has to wonder why
someone asks for this and specifically mentions a documented technical
limitation of the obvious answer to the question.
Since ->can, like ->DOES and any other way of enabling subroutines
which are not part of a class to make 'control flow descision' based
on the 'type' of some object shouldn't really exist to begin with (the
point of overloading is to eliminate explicit 'switching based on type
fields'), that's a small cost to pay.
A relatively trivial implementation is possible but I won't provide an
example here since this would be asking for another 'sideline
offensive'.
------------------------------
Date: Thu, 07 Mar 2013 15:29:16 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: moving class indepdent methods out of class definitions
Message-Id: <87mwuf9qk3.fsf@sapphire.mobileactivedefense.com>
... and into places where they can be reused by other classes,
including the possibility to 'overload' them in derived classes (not
necessarily sensible for class-independent code): Put them into a
package which exports them. Import them into the class package. That's
'roles in a nutshell' and the answer is actually so trivial (and
obvious) that I'm wondering why 'experienced perl programmers' ask
such questions.
------------------------------
Date: Wed, 6 Mar 2013 23:33:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <na0l0a-sul2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.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.
Let's recap, shall we?
- This subthread started with my assertion that, in Perl, attributes
should always be wrapped in accessor methods, since that makes
subclassing easier;
- you found this concept 'mind-boggling', since apparently you
believe that methods which only call other methods should not be
part of a class (you have yet to explain where you think they
*should* go...);
- I asked you to explain this belief;
- your explanation was that 'that's how it happens to work in Perl
(or in other OO system structured around 'message passing')';
- I pointed out that Perl's OO is not particularly structured around
message passing, at least not as I understand the term; I also
pointed out that since Perl doesn't have generics or multimethods
there isn't anywhere to put functionality related to a class of
objects *except* in the class.
I don't think I'm the one talking in circles.
Ben
------------------------------
Date: Wed, 6 Mar 2013 23:59:24 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <sr1l0a-37m2.ln1@anubis.morrow.me.uk>
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> >
> > 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.
Polymorphism is central to this discussion. My original point was that
attributes should be wrapped in methods rather than accessed directly in
order that subclasses can replace those attributes with methods if they
need to. The fact that Perl does not have generics, and therefore the
only way to achieve polymorphism is through ordinary methods, came up in
response to your statement that I ought to be using generics.
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Ben Morrow <ben@morrow.me.uk> writes:
> >> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> >>
> >> >> 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.
It's not. You said that 'charge' should not be a method of Book, since
it's more generic than that. What, then, should it be, and how should it
be invoked on a given Book?
> > Now suppose I have a different situation. I have Book and Book::InSeries
> > objects as before, which should use this charge function:
[...]
> >
> > 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.
Hmm... maybe that's the problem here: you seem to think these examples
all need different solutions. I think they all have solutions in the
same form, namely classes and subclasses, with methods inherited where
that is useful and overridden where it isn't.
Central to my original point was the idea that requirements change over
time, and that code should be written in such a way that those changes
can be allowed for without having to rewrite everything you've already
done. If you have to redesign your whole application from scratch every
time some little detail changes you end up doing far more work than you
needed to.
> "Wer Ohren hat, der hoere. Wer nichts hoeren will der laessts
> halt". Pax Hibiscus.
Ich spreche nicht Deutsch.
[Those that have ears will hear. Those that hear nothing want... ???]
Ben
------------------------------
Date: Thu, 07 Mar 2013 02:59:09 -0800
From: Steve May <stevem_@nogood.com>
Subject: Re: some random remarks about Moose::Manual::Concepts
Message-Id: <3q_Zs.188708$uU.132977@newsfe11.iad>
On 03/06/2013 03:33 PM, Ben Morrow wrote:
>
> Quoth Rainer Weikusat <rweikusat@mssgmbh.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.
>
> Let's recap, shall we?
>
> - This subthread started with my assertion that, in Perl, attributes
> should always be wrapped in accessor methods, since that makes
> subclassing easier;
>
> - you found this concept 'mind-boggling', since apparently you
> believe that methods which only call other methods should not be
> part of a class (you have yet to explain where you think they
> *should* go...);
>
> - I asked you to explain this belief;
>
> - your explanation was that 'that's how it happens to work in Perl
> (or in other OO system structured around 'message passing')';
>
> - I pointed out that Perl's OO is not particularly structured around
> message passing, at least not as I understand the term; I also
> pointed out that since Perl doesn't have generics or multimethods
> there isn't anywhere to put functionality related to a class of
> objects *except* in the class.
>
> I don't think I'm the one talking in circles.
>
> Ben
>
Ben,
I've been following your posts in this thread and for what it's worth
you've managed to clarify a few perlish OO concepts for me, at least.
Thanks,
Steve
------------------------------
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 3895
***************************************
