- Original Message -
From: "chromatic" <[EMAIL PROTECTED]>> I would expect 'does' instead of
'isa'. Perhaps I missed Dan's
> explanation of the difference between 'can', 'isa', and 'does'. Maybe
> I'm thinking of 'has', though.
Though I'm not familiar with the answer that's "official" fo
It occurred to me tonight, that those looking for a compiler project
involving Parrot might consider a Sather compiler. It'd have to wait
for objects(and thus likely Parrot 0.1), but it'd be an interesting
language to have available as a testing tool for the object-oriented
capabilities of Par
On Sunday, March 16, 2003, at 05:09 PM, David Storrs wrote:
==QUESTION
- Page 8 says "In some languages, all methods are multimethods." I
believe that Java is one of these. Is that right and what are some
others? (This is really just curiousity.)
==/
Doesn't C++ work this way? Also I believe P
On Thursday, March 13, 2003, at 02:13 PM, Jonathan Scott Duff wrote:
I don't think that junctions make sense here. Besides, the "is" is
optional:
class Foo {
method bar is public rw const frob knob { ... }
}
Ah yes, I'd forgotten about this. Thanks. Still I wond
This may have been asked before, and I apologize if I somehow missed it,
but can junctions be used for multiple properties?
I can see it possibly being useful in a situation like the
following(which may be completely off, as I'm still digging my way
through A6):
class Foo {
method bar is p
On Friday, January 10, 2003, at 11:49 AM, Dan Sugalski wrote:
At 1:37 PM + 1/10/03, Peter Haworth wrote:
This will mean we can't support Eiffel
Nope. :)
What it means is that the proposed base object system won't work for
eiffel.
Actually, if you really want Eiffel to compile to Parrot,
On Thursday, January 9, 2003, at 05:36 AM, Damian Conway wrote:
Chris Dutton wrote:
@ages[*] = $today - %date_of_birth{@names}.values[*]
Well done. Thanks for working that out, Chris. And, in the process,
confirming my sense that vector ops are a better solution here.
;-)
Glad I could
On Wednesday, January 8, 2003, at 01:32 PM, Michael Lazzaro wrote:
On Wednesday, January 8, 2003, at 02:13 AM, Damian Conway wrote:
Michael Lazzaro wrote:
The remaining big question, then, is whether you can truly subclass
Array to achieve C-like behavior:
class MyArray is Array { ... };
On Tuesday, January 7, 2003, at 11:20 PM, Damian Conway wrote:
Chris Dutton wrote:
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Interesting, but I still feel that
On Friday, January 3, 2003, at 12:00 PM, Chris Dutton wrote:
print "date" if 1..31 given $var;
Except that this would always be true. Nevermind, I'm an idiot.
On Friday, January 3, 2003, at 08:55 AM, Smylers wrote:
Murat Ünalan wrote:
print "date" if $var is int( 1..31 );
I don't think that the type needs to be specified here, especially if
the variable has already been declared to be of the required type, so a
junction should be sufficient:
pri
Given discussions about "hyper" operators in the past, I found this
rather interesting in the release notes.
http://pike.idonex.com/download/notes/7.4.10.xml
Automap
To perform per-element operations on arrays, there is now a convenience
syntax for map(), that can make code more readable in som
On Thursday, December 12, 2002, at 01:11 PM, Michael Lazzaro wrote:
We can make that
@out = @in.grep({...}).map({...}).sort;# [2]
if we want to grind our OO axe, but I find that syntax disappointing.
I like that the idea is important enough in Perl to have it's own
grammar, but I rea
On Friday, December 6, 2002, at 04:28 AM, Joseph F. Ryan wrote:
Brent Dax wrote
To tell you the truth, I don't consider arrayrefs references anymore.
They're just Array objects that don't happen to be in @whatever
symbols.
I don't know if this is the official view, but that fits my brain
bette
On Thursday, October 31, 2002, at 10:03 PM, John Siracusa wrote:
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
Damian Conway writes:
BTW, Both Larry and I do understand the appeal of interleaving
sources and iterators. We did consider it at some length back
in January, when we spent a week thr
So many operators...
It's now clear what we need. Unicode operators. That should buy us at
least another week to hash out the rest of the necessary operators. ;-)
It'd also silence the legions of critics who complain about Perl being
too easy to read if we, for instance, used the Kanji charac
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like "like" the best, actually...
Hmmm... I could actually see "like" in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except th
On Saturday, October 12, 2002, at 01:10 PM, Luke Palmer wrote:
>> Date: Sat, 12 Oct 2002 08:43:46 -0700 (PDT)
>> From: Larry Wall <[EMAIL PROTECTED]>
>>
>> If we use | and & as sugar for any() and all(), then their precedence
>> should probably be the same as || and &&.
>
> Should they? I had i
On Wednesday, October 9, 2002, at 05:03 PM, Trey Harris wrote:
> In a message dated Wed, 9 Oct 2002, Michael Lazzaro writes:
>
>>
>> Uh-oh: my life is gonna suck. I've spent days hunting obscure bugs
>> that were caused by a single mistyped character. Now I'll be spending
>> days hunting obsc
One first thing I notice while I'm supposed to be doing homework. :-)
Wasn't "class MyClass;" supposed to work along the line of Perl5's
"package MyClass;" and make everything following that statement the
definition of MyClass?
On Sunday, October 6, 2002, at 12:57 AM, Noah White wrote:
>>
>>> Note that an alternate definition of "private" is often used, as
>>> follows:
>>>
>>> A "private" attribute is an attribute whose scope is restricted
>>> such that
>>> it may be accessed only within the class in which it
On Friday, October 4, 2002, at 06:23 PM, [EMAIL PROTECTED] wrote:
> On Fri, Oct 04, 2002 at 09:13:45AM -0400, Chris Dutton wrote:
>>> How exactly does one "weaken" a precondition?
>>
>> At least in Eiffel, if you redefine a method, you may not give it
On Thursday, October 3, 2002, at 05:19 PM, Michael G Schwern wrote:
> On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote:
>> With pre/post conditions, a subclass is allowed to weaken the
>> preconditions or strengthen the postconditions.
>
> How exactly does one "weaken" a precondition
On Monday, September 30, 2002, at 11:19 PM, Michael G Schwern wrote:
> On Mon, Sep 30, 2002 at 06:04:28PM -0700, David Whipp wrote:
>> On a slightly different note, if we have interfaces then I'd really
>> like to follow the Eiffel model: features such as renaming methods
>> in the derived class
Using Mac OS X 10.1.5, on which I've successfully built 0.0.6 and 0.0.7.
[localhost:~/parrot.1/languages/imcc] chris% make
anyop.o definition of _n_symbols in section (__DATA,__common)
make: *** [imcc] Error 1
[localhost:~/parrot.1/languages/imcc] chris%
Then when I try to run a simple "Hel
We are supposedly going to be able to set a class to be
"uninheritable". Will we be able to set a single method or attribute to
be uniherited by any subclasses? Please forgive me if this is one of
the seven deadly OO sins. I haven't yet had any formal education with
regards to programming(a
Explained far more throughly at http://pike.ida.liu.se/ than I can in an
e-mail.
It really looks like an intriguing language, with a (supposedly) very
fast runtime, (again, supposedly) beating Perl, Python, Tcl, and Java in
execution times. Unfortunately I've been unable to get it to compile
On Tuesday, August 20, 2002, at 01:11 AM, Sean O'Rourke wrote:
> This is a weird implementation artifact, which should probably be
> documented. While real Perl gathers up all the statements you put
> outside
> of any function into a sort of "main", for the time being you'll need to
> put all t
Maybe I'm just doing something wrong...
I make parrot, which goes smoothly, then make IMCC, which chokes on
"long long". Then I "perl pconfig.pl" and "make" and after two or three
tries a full Perl6grammar.pm magically shows up. I'm still scratching
my head over that one.
Then when I try to
and this just jumped out at me:
class Foo {
private string|int bar;
static create(string|int newBar) {
bar = newBar;
}
}
In other words, as I understand it, you can type the variable bar as
either an int or a string.
Aside from simply, "my $bar;", w
On Monday, August 12, 2002, at 01:27 PM, Allison Randal wrote:
> On Sat, Aug 10, 2002 at 07:30:19PM -0400, Chris Dutton wrote:
>>
>> The only problem I could see, and I wanted to wait for at least one
>> other opinion before mentioning this, is rewriting the above as
On Saturday, August 10, 2002, at 06:25 PM, Piers Cawley wrote:
> Chris Dutton <[EMAIL PROTECTED]> writes:
>
>> Since Adam Lopesto asked a non-regex question, I don't feel quite as
>> out of place for doing the same.
>>
>> This one actually came
Since Adam Lopesto asked a non-regex question, I don't feel quite as out
of place for doing the same.
This one actually came to me just the other night. Would it be possible
in Perl 6 to create "anonymous classes"? Something like:
my $foo_class = class {
method new {
On Wednesday, May 15, 2002, at 10:17 AM, Aaron Sherman wrote:
> On Sat, 2002-05-11 at 13:58, Chris Dutton wrote:
>
>> method world is public_to(Bar) {
>
> Might as well make that:
>
> method world is private(Bar)
>
> I tend to take any opportunity to recy
On Sunday, May 12, 2002, at 02:18 PM, Miko O'Sullivan wrote:
>> While thinking Eiffel-ish thoughts the other day, I began to wonder if
>> Perl6's classes could go beyond the simple private/public/protected
>> scheme by optionally allowing for a property or method to only be
>> accessed by a cert
While thinking Eiffel-ish thoughts the other day, I began to wonder if
Perl6's classes could go beyond the simple private/public/protected
scheme by optionally allowing for a property or method to only be
accessed by a certain set of classes. For instance(as I understand
Perl6 syntax):
class
On Friday, May 10, 2002, at 09:54 PM, Damian Conway wrote:
> That's getting a little ugly, so maybe we'd "lift" the syntax from
> Eiffel instead:
>
> method set_baz($newbaz is like($.baz)) { $.baz = $newbaz }
This is exactly what went through my mind about a half second after I
posted
On Thursday, May 9, 2002, at 03:16 PM, Aaron Sherman wrote:
> Then you can declare them as such:
>
> sub get_bar() { .bar }
> sub get_baz() { .baz }
> sub set_baz($newbaz) { .baz = $newbaz }
Seeing this, an idea mildly Eiffel-ish comes to mind. Could we get away
with somethin
On Tuesday, April 30, 2002, at 01:22 PM, Dan Sugalski wrote:
> At 1:07 PM -0400 4/30/02, Miko O'Sullivan wrote:
>> > Damian, now having terrible visions of someone suggesting
>> C ;-)
>>
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep,
>> elstry ...
>
> Has anyone brought
39 matches
Mail list logo
