Re: Cya dudes
> The Perl-KGB-elite has got to go, and a free republic must replace
> it.
I wouldn't go as far as your entire post, neither in form nor content,
but I do have concerns about the sociopsycho(patho)logy of the Perl
community.
Personally I'm very concerned about the 'every RFC should have an
implementation section' near-requirement. Or the 'if you're not coding
the internals your input is most likely bullshit' stance of some of
our self-appointed 'leaders'. Having been programming for 15 years
now, I have seen proof, again and again, that the ability to code
doesn't correlate with the ability to design.
Many valuable programmers use Perl in very competent fashions, solving
- sometimes - very complex problems. Sometimes they encounter a
situation that proves that this or that language feature is
useful. That they should drop everything they're doing and spend the
next quarter mastering the internals of Perl, just in order to code
the said feature - indeed in order for having a chance of being heard
by some - and then, when they're done, probably return to their
previous concerns, and probably never use the hard-gained knowledge,
seems to me like a complete waste of time, energy and intelligence.
On a different, yet related issue: had there been a perl6-sociology
list, I would have submitted the following:
All newbies are not necessarily 'clueless newbies'
There.
--
Jean-Louis Leroy
http://users.skynet.be/jll
Re: Against overloading || and && (RFC 20) -- we just need lazy evaluation
Bart Lateur <[EMAIL PROTECTED]> writes: > OK, how about this idea then. && and || still work as they did, but you > provide a callback method (say, TRUTH or BOOLEAN) that says whether this > particular object is true or false. So: You don't take into account using && and || to build trees for later evaluation, which is probably the most frequent *valid* use of these techniques. This is what I use them for in Tangram. Have you actually read my RFC? Just because there'll be people who will misuse the feature doesn't mean that Perl should not have it. Also, as I point out, it *is* possible to support short-circuiting for user-defined logical junctions. -- Jean-Louis Leroy http://users.skynet.be/jll
Re: Against overloading || and && (RFC 20) -- we just need lazy evaluation
Bart Lateur <[EMAIL PROTECTED]> writes: > Actually, we don't need it. All we need, is lazy evaluation. > > The idea comes from Lisp, where you have a possibility to create > ordinary looking functions (in Lisp, there's no difference between a > function and an operator; the less polite name is "prefix notation"); > but the calculation of the values of the parameters can be postponed > until the time when the sub is already running. In fact, it won't be > calculated, unless you invoke it yourself. (How? "eval"?) How is that against RFC 20? I described such a mechanism there... -- Jean-Louis Leroy http://users.skynet.be/jll
Re: RFC 54 (v1) Operators: Polymorphic comparisons
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: > Currently the expression: > > "cat" == "dog" > > returns true. And you want to remove it? Hey, I always get great fun from explaing that when I give Perl courses. What else? Allow accents in identifiers (fun #1 when teaching Perl or C++ in French)? -- Jean-Louis Leroy http://users.skynet.be/jll
Re: Safer OO inheritance
Bart Lateur <[EMAIL PROTECTED]> writes:
> The problem is that you can't safely subclass a class, without examining
> it's source, just to make sure that your instance fields don't clash
> with any private fields of the mother class.
Well...let's think twice. What has the reputatin of being a bug or a
shortcoming in Perl is actually a feature in CLOS.
In the C++ View of the World you should be able to derive from a class
without examining the bases - especially the indirect bases. I thought
it made sense for years.
Until I realized that the 'miraculous reuse by accident' is a complete
lure. Which did a lot of harm to the reputation of OO. I now believe
that reuse is the consequence of ad-hoc design and cooperation between
the involved classes, that it has to be planned for and that it has a
cost - typically two or three times the cost of a non-reusable
design. Someone even said that the word 'reuse' made it look too
simple and suggested using the word 'polybloodyhardreuse' instead
Thus, regardless of the issue about field inheritance, I believe that
"you can't safely subclass a class, without examining it's source" (or
its documentation, which should spell out the existence and purpose of
each field).
Also, consider what happens in presence of multiple inheritance,
particularly in the 'mixin' style. Typically you want to share a
single base sub-object even if a class is inherited more than once
(iow you want what C++ calls 'virtual inheritance'). Currently, in
Perl you get that by default. If you introduce scoped fields (by
default), you'll also have to introduce two kinds of inheritance:
shared and repeated.
I'm more in favor of a mechanism that makes it easy to build field
names from the package name, for those rare cases where you want
scoped fields. There were discussions about this a couple of years ago
on p5p. For example:
package Foo;
sub new
{
bless { "${CURRENT_PACKAGE}name" => 'Simpson' ...
}
...where $CURRENT_PACKAGE is a special variable automatically set
to...guess what? ;-)
--
Jean-Louis Leroy
http://users.skynet.be/jll
Re: RFC 18 (v1) Immediate subroutines
Dan Sugalski <[EMAIL PROTECTED]> writes: > This does complicate the job of the parser/lexer rather > considerably. Why? Isn't it 'just' a matter or making the lexer read from a hot-redirectable input stream? Hmm. Such a bold statement from someone who's never contributed a patch (to Perl) -- Jean-Louis Leroy http://users.skynet.be/jll
Re: RFC 18 (v1) Immediate subroutines
"Michael Mathews" <[EMAIL PROTECTED]> writes: > I have updated the Multiline Comment RFC with responces and conclusions > based on the feedback that has been submitted so far. If you are presenting > this example as an alternative/addition to the suggestions made there (so > far) I would strongly encourage you to read what has already been discussed, > particularly the problems with using a function or subroutine-like > mechanisms for commenting arbitrary blocks of code. Will do. Note, however, that multiline comments are one of the many possible uses of the proposed feature. -- Jean-Louis Leroy http://users.skynet.be/jll
