Ovid [EMAIL PROTECTED] writes:
--- Piers Cawley [EMAIL PROTECTED] wrote:
How about:
my method SCALAR::attributes($self:) { $$self }
my method HASH::attributes(%self:) { %self.kv }
my method ARRAY::attributes(@self:) { [EMAIL PROTECTED] }
method _attributes($attrs) {
my
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up the inheritence
tree. Personally, I've always thought a cascade method
All~
On 10/13/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases where you're actually calling all the way up
On Oct 13, 2005, at 9:47 AM, Matt Fowles wrote:
On 10/13/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Luke Palmer [EMAIL PROTECTED] wrote:
Okay, I seriously have to see an example of a submethod in use.
Likewise. As far as I've seen, submethods are a kludge wedged in for
cases
I think this is an opportune time for me to express that I think the
ability to close-source a module is important. I love open source,
and I couldn't imagine writing anything by myself that I wouldn't
share. But in order for Perl to be taken seriously as a commercial
client-side language,
On Thu, Oct 13, 2005 at 03:01:29PM -0400, Rob Kinyon wrote:
I think this is an opportune time for me to express that I think the
ability to close-source a module is important. I love open source,
and I couldn't imagine writing anything by myself that I wouldn't
share. But in order for
HaloO,
Stevan Little wrote:
On Oct 11, 2005, at 8:47 PM, Larry Wall wrote:
You seem to be arguing that a class has no state, but my view is that,
in the abstract, a class encompasses the state of *all* its objects.
It just hasn't picked one particular object to be at the moment.
I love this
(ref: http://svn.openfoundry.org/pugs/docs/notes/theory.pod)
theory Ring{::R} {
multi infix:+ (R, R -- R) {...}
multi prefix:- (R -- R){...}
multi infix:- (R $x, R $y -- R) { $x + (-$y) }
multi infix:* (R, R -- R) {...}
# only technically
On Oct 13, 2005, at 6:45 PM, Dave Whipp wrote:
I started thinking about the in general, unverifiable
programmatically bit. While obviously true, perhaps we can get
closer than just leaving them as comments. It should be possible to
associate a unit-test-generator with the theory, so I can
On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote:
Closed classes should not exist.
At least, they should only exist if the person *running* Perl 6 wants
them to exist -- never if merely the class writer wants to close them.
In theory I agree, and I hope that will be the defacto way of
On Oct 13, 2005, at 4:45 PM, TSa wrote:
No, not that class has no state, but that with the currently
specced classes we have inherited behaviors (class methods) but
they do not inherit the accompanying state (class attributes) as
well. I see this as potentially very problematic.
David Storrs wrote:
While I like the idea, I would point out that 1000 tests with randomly
generated data are far less useful than 5 tests chosen to hit boundary
conditions.
I come from a hardware verification background. The trend in this
industry is driven from the fact that the
Well, I suspected there would not be much support for my initial
proposal on class methods, but I felt I had to try. Not being the
type of person who gives up easily, I want to revise the proposal
(incorporating some of the ideas in the responses).
I propose that class methods are
On Fri, 2005-10-14 at 02:18 +0200, Yuval Kogman wrote:
On Wed, Oct 12, 2005 at 13:08:27 -0700, chromatic wrote:
Closed classes should not exist.
At least, they should only exist if the person *running* Perl 6 wants
them to exist -- never if merely the class writer wants to close them.
On Thu, Oct 13, 2005 at 06:13:09PM -0700, chromatic wrote:
I just don't want people who merely write a module or class to be
able to prevent people who actually use that module or class from
using, extending, or poking around in it.
Sounds kind of like Linus's opinion of close-source modules.
On 14/10/05, Stevan Little [EMAIL PROTECTED] wrote:
So anyway, here are a few ideas, in no particular order:
method bark (::Dog $d:) { ... }
# not sure if this notation is already taken or not
method bark ($Dog $d:) { ... }
# not sure I like this one myself, but to me it helps
I retract my opposition to err. After coding this:
try
{
try { path = f.getCanonicalPath(); }
catch (Exception e) { path = f.getAbsolutePath(); }
}
catch (Exception e) { path = f.toString(); }
I am now a convert. To the extent that we are
Hey All,
So, given the abundance of positive responses ;) for my class
methods don't inherit proposal, I have decided to withdraw that
proposal (see my last response on the thread). Of course, this means
we now have to work out the details of exactly *how* they get
inherited in all
18 matches
Mail list logo
