Luke Palmer skribis 2006-08-24 23:57 (-0600):
Let's say our arrays are simple, for argument's sake: With a constant
array, you can:
* get its length
* get the value of an element at an index
With an array, you can:
* get its length
* get the value of an element at an index
* set
On 8/25/06, Juerd [EMAIL PROTECTED] wrote:
You define in terms of functionality, but don't provide an explanation
for the chosen point of view. One could say that constant arrays protect
against
modifications, which normal arrays don't. Hence, constant arrays do *more*.
I think the
On Wed, Aug 23, 2006 at 04:10:32PM -0700, Larry Wall wrote:
Yes, that should work eventually, given that hypers are supposed to stop
after the longest *finite* sequence. In theory you could even say
my %trans = ('a'..*) »=« ('?' xx *);
but we haven't tried to define what the semantics
On Fri, Aug 25, 2006 at 08:40:59AM -0400, Mark J. Reed wrote:
: On 8/25/06, Juerd [EMAIL PROTECTED] wrote:
: You define in terms of functionality, but don't provide an explanation
: for the chosen point of view. One could say that constant arrays protect
: against
: modifications, which normal
I asked this same question on perl6-users, but no one really seemed to have
a definitive answer, so please forgive me for reasking.
I was wondering how named arguments would work when parameters of different
types had the same name, ie sub foo($bar, @bar, bar) {...}. I wrote a
little script to
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
I think the justification for Luke's POV is the number of operations
each class provides. But my perspective agrees with Juerd -
subclasses can remove functionality as well as adding it, and I
definitely view constant as an add-on
On 8/25/06, Trey Harris [EMAIL PROTECTED] wrote:
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
I think the justification for Luke's POV is the number of operations
each class provides. But my perspective agrees with Juerd -
subclasses can remove functionality as well as adding
In a message dated Fri, 25 Aug 2006, jerry gay writes:
perhaps trey meant subclasses can add constraints as well as
functionality instead of subclasses can remove functionality as well
as adding it.
just a guess.
~jerry
Ok... same thing from a DBC perspective. Subclasses can add
On 8/25/06, Trey Harris [EMAIL PROTECTED] wrote:
subclasses can remove functionality as well as adding it
Can someone suggest some reading I can do to understand how that works?
I can't wrap my head around the idea of subclasses removing functionality.
Why not? Is it any weirder than
Does this mean you can't write
class Super { method something { ... } }
sub foo (Super $bar) { $bar.something() }
and expect foo($obj) to work, because $obj might be:
class Sub is Super { # remove .something--how does that happen? }
foo($obj); # Boom!?
So what happens?
Author: larry
Date: Fri Aug 25 12:28:00 2006
New Revision: 11421
Modified:
doc/trunk/design/syn/S06.pod
Log:
Discussed relationship of is syntax to adverb syntax and type syntax.
Nailed down some (hopefully) sane default behaviors for equiv and assoc.
Modified: doc/trunk/design/syn/S06.pod
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
On 8/25/06, Trey Harris [EMAIL PROTECTED] wrote:
subclasses can remove functionality as well as adding it
Can someone suggest some reading I can do to understand how that works?
I can't wrap my head around the idea of subclasses
On Fri, Aug 25, 2006 at 12:38:33PM -0700, Trey Harris wrote:
: But in order to allow that choice, the language has to impose some
: groundrules for everyone. strict couldn't exist in Perl 5 if lexicals
: could autovivify. And--*by my understanding of DBC*--subclasses can't
: remove promised
OK, I admit I wasn't thinking about things from a DBC perspective, and
misunderstood DBC to be a reference to some database module. I here
am new and I didn't have context. My bad.
But if we're talking design-by-contract, I don't see how Array is
Array::Const can work, either, since I consider
On 8/25/06, Mark J. Reed [EMAIL PROTECTED] wrote:
I here am new and I didn't have context.
Well, technically, I here am not new; I've been here since before Apoc
1. But I hadn't been paying close attention for a while until
recently. :) Either way, I didn't get the ref.
--
Mark J. Reed
If changing that functionality beyond recognition means changing its
external behavior (as opposed to its internal behavior) so that it
acts differently from what the superclass had promised to do, then
no, it's not any weirder--but I can't figure out how the contract
would work, either.
Trey Harris skribis 2006-08-25 11:33 (-0700):
Ok... same thing from a DBC perspective. Subclasses can add functionality
(by AND'ing postconditions), or remove constraints (by OR'ing
preconditions), but they can't traditionally remove functionality or add
constraints. I just want to read
In a message dated Fri, 25 Aug 2006, Mark J. Reed writes:
OK, I admit I wasn't thinking about things from a DBC perspective, and
misunderstood DBC to be a reference to some database module. I here
am new and I didn't have context. My bad.
But if we're talking design-by-contract, I don't see
In a message dated Fri, 25 Aug 2006, Juerd writes:
Trey Harris skribis 2006-08-25 11:33 (-0700):
Ok... same thing from a DBC perspective. Subclasses can add functionality
(by AND'ing postconditions), or remove constraints (by OR'ing
preconditions), but they can't traditionally remove
Trey Harris skribis 2006-08-25 13:26 (-0700):
Explain to me how nontraditional DBC might work in an internally
consistent way. Otherwise, this is hand-waving. :-)
Perl *is* hand-waving.
In a message dated Fri, 25 Aug 2006, Daniel Hulme writes:
If changing that functionality beyond recognition means changing its
external behavior (as opposed to its internal behavior) so that it
acts differently from what the superclass had promised to do, then
no, it's not any weirder--but I
In a message dated Fri, 25 Aug 2006, Juerd writes:
Trey Harris skribis 2006-08-25 13:26 (-0700):
Explain to me how nontraditional DBC might work in an internally
consistent way. Otherwise, this is hand-waving. :-)
Perl *is* hand-waving.
Yeah, but hand-waving on how it manages the behavior
On Fri, Aug 25, 2006 at 02:04:01PM -0700, Trey Harris wrote:
: In any case, Larry's settled this issue.
Nah, I just handwaved it harder. :)
Larry
On Fri, Aug 25, 2006 at 01:25:23PM -0700, Trey Harris wrote:
: I think Larry nailed it with his observation about the difference between
: class and role and trait. 'Constant' is a trait of another type, not a
: type into itself.
Hmm, well, there are several hands to be waved here. First,
On 8/25/06, Mark J. Reed [EMAIL PROTECTED] wrote:
Why not? Is it any weirder than simply changing that functionality
beyond recognition?
You can always fake removing functionality even if the language
doesn't actually support it.
Yes, yes, of course. That is not the issue. We are trying to
On 8/25/06, Daniel Hulme [EMAIL PROTECTED] wrote:
That's because you're used to one way of thinking about class
inheritance: that the subclass can do everything that the superclass can
do, and more. In this scheme, you might have a Square class, with a
field representing its corner and another
On 8/25/06, Michael Snoyman [EMAIL PROTECTED] wrote:
I asked this same question on perl6-users, but no one really seemed to have
a definitive answer, so please forgive me for reasking.
I was wondering how named arguments would work when parameters of different
types had the same name, ie sub
Perl6::Spec::Documentation is a draft spec for documentation formats for
use with Perl6.
My own reading of it is that POD still exists and is supported, while a
new wiki-like format kwid is added, and a framework for various
dialects is supported.
POD was successful for its simplicity. It was
28 matches
Mail list logo
