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
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 langua
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
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 n
(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) {...}
># on
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 ca
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
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.
What
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 computer
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 inheritab
On 10/13/05, John Macdonald <[EMAIL PROTECTED]> wrote:
> Just because you can't make locking perfect does not mean it
> has no value.
Acme::Bleach it is!
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 clos
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
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 situ
On Thu, 2005-10-13 at 18:36 -0700, Chip Salzenberg wrote:
> 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
On 10/13/05, Dave Whipp <[EMAIL PROTECTED]> 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
20 matches
Mail list logo
