HaloO Larry,
you wrote:
On Tue, Jul 12, 2005 at 08:13:22PM +0200, TSa (Thomas Sandlaß) wrote:
: Actually it's a pitty, that the multi method call syntax isn't as
: rich as the single method call syntax where we have .?method, .+method
: and .*method. Something like (Snoopy, Mr_PotatoHead,
TSa (Thomas Sandlaß) wrote:
Unique least-inherited most-specialized match, or default
Do I read this correctly as dispatching partly in the class hierarchy
and partly in the type hierarchy?
Err. The class hierarchy *is* the type hierarchy in Perl 6.
Or do you mean with
TSa (Thomas Sandlaß) wrote:
Is there also an answer to the odering versus metric question?
Why was the former rejected and the latter choosen?
MMD is really just a partitioning of the discrete N-dimensional search space
formed by the class hierarchies of the N parameters of a
HaloO Damian,
thank you very much for your explaination. I just want to hint the
Perl6 community to the fact that there exists a US patent on geometric
MMD:
On Tue, 12 Jul 2005, Larry Wall wrote:
Good, I'd forgotten about that. Which means that it's even harder
for someone to compile a module in a strange dialect, since they'd
essentially have to write their own version of use that forces
recompilation (reuse, if you will). And the harder we make
Damian Conway wrote:
Important qualification:
Within a method or submethod, C.method only works when C$_ =:=
$?SELF.
C.method is perfectly legal on *any* topic anywhere that $?SELF
doesn't exist.
Just to be clear, this includes any method/submethod with an explicitly
named invocant,
Hi,
Michele Dondi wrote:
Good, I'd forgotten about that. Which means that it's even harder
for someone to compile a module in a strange dialect, since they'd
essentially have to write their own version of use that forces
recompilation (reuse, if you will). And the harder we make it to
Dave Whipp skribis 2005-07-13 8:44 (-0700):
Within a method or submethod, C.method only works when C$_ =:=
$?SELF.
C.method is perfectly legal on *any* topic anywhere that $?SELF
doesn't exist.
Just to be clear, this includes any method/submethod with an explicitly
named invocant, I
Sorry, instead of implicit 'commit', I mean to say implicit conversion.
-
Ron Reidy
Lead DBA
Array BioPharma, Inc.
-Original Message-
From: Reidy, Ron
Sent: Wednesday, July 13, 2005 9:06 AM
To: Sam Vilain; Dean Arnold
Cc: dbi-users@perl.org; dbi-dev@perl.org;
On Wed, Jul 13, 2005 at 05:10:14PM +0200, Michele Dondi wrote:
: On Tue, 12 Jul 2005, Larry Wall wrote:
:
: Good, I'd forgotten about that. Which means that it's even harder
: for someone to compile a module in a strange dialect, since they'd
: essentially have to write their own version of use
-Original Message-
From: Sam Vilain [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 12, 2005 5:04 PM
To: Dean Arnold
Cc: dbi-users@perl.org; dbi-dev@perl.org; perl6-language@perl.org
Subject: Re: DBI v2 - The Plan and How You Can Help
Dean Arnold wrote:
RE: LOBs and SQL Parse Trees:
Hello,
More questions for the metamodel. I am trying to add proper submethod
and private method handling and I have a question about method
resolution order as a whole. I asked a similar question last week, but
this time I have more details :)
Given this class:
class Foo {
On Wed, Jul 13, 2005 at 06:11:32PM +1000, Damian Conway wrote:
: TSa (Thomas Sandlaß) wrote:
:
: Unique least-inherited most-specialized match, or default
:
:
: Do I read this correctly as dispatching partly in the class hierarchy
: and partly in the type hierarchy?
:
: Err. The class
You guys are beating a live horse. Apocalypse 5 already
discusses arrays pretending to be strings for the sake of parsing.
The capability has to be there, and in fact Patrick has been bearing
that in mind in the design of PGE. The only question for p6l is how
much syntactic sugar you want.
I've
On Wed, Jul 13, 2005 at 12:51:49PM -0400, Stevan Little wrote:
: Hello,
:
: More questions for the metamodel. I am trying to add proper submethod
: and private method handling and I have a question about method
: resolution order as a whole. I asked a similar question last week, but
: this
On Jul 13, 2005, at 1:12 PM, Larry Wall wrote:
If class Dog does role Bark and also does role Wag, then passing a
Dog to
multi (Bark $x)
multi (Wag $x)
should result in ambiguity.
My understanding is that a Role is an abstract (i.e. cannot be
instantiated) blob of methods and,
On Tue, Jul 12, 2005 at 04:43:06PM +0530, Aankhen wrote:
: I agree with what is being said here. `.method` is a great way to
: eliminate a lot of repetitive, tedious typing. Surely there is a
: viable alternative that doesn't involve outlawing it?
Certainly. The problem is that there are too
On Wed, 2005-07-13 at 17:33 -0400, David Storrs wrote:
What is a type besides a named blob of methods
and, possibly, data?
A label that says how the data is stored internally. For example,
compare Int and int. The former is a type and a blob of methods
and not necessarily
Dean Arnold wrote:
Column 3 is a BYTEA column in Pg and needs special peppering to work.
What sort of peppering ? DBI provides SQL_BLOB, and SQL_CLOB
type descriptors (as well as SQL_BLOB_LOCATOR and SQL_CLOB_LOCATOR), so
presumably DBD::Pg (or any other DBD supporting LOBs) provides the
logic
The proposals so far have dealt mostly with the SQL itself, and
supporting database-neutral layers on top of DBI.
Personally, I don't mind writing the SQL myself, I rarely need to make
a particular statement work on two databases in my work, and I can
optimize a lot better than any SQL generator.
Larry,
On Jul 13, 2005, at 2:30 PM, Larry Wall wrote:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However,
it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that
On Wed, Jul 13, 2005 at 05:33:18PM -0400, David Storrs wrote:
: I'd like to have it explained what Roles
: offer that justifies their existence, since they won't be anything
: but a restricted form of a class.
Please check your assumptions.
In addition to what chromatic said, I'd like to
(Taking things slightly out of order.)
On Jul 13, 2005, at 7:32 PM, Larry Wall wrote:
A class is
restricted to having to provide a working interface to real objects.
Can't there be pure-abstract, non-instantiable classes? Or are you
still considering those to be interfaces to real
TSa (Thomas Sandlaß) wrote:
I just want to hint the Perl6 community to the fact that there exists
a US patent on geometric MMD:
Well, fortunately it's really just a patent on the specific combination of a
mathematical isomorphism and a well-known geometric algorithm to *optimize*
method
On Tue, Jul 12, 2005 at 08:48:41PM +0300, Gaal Yahas wrote:
: I propose to throw away the filesystem coupling, and map from a more
: general name of the bit of code we are requiring to a more general
: description of which instance of it we actually got. Once modules return
: interesting values,
On Tue, Jul 12, 2005 at 02:10:06PM -0700, Larry Wall wrote:
Good, I'd forgotten about that. Which means that it's even harder
for someone to compile a module in a strange dialect, since they'd
essentially have to write their own version of use that forces
recompilation (reuse, if you will).
Larry Wall wrote:
In addition to what chromatic said, I'd like to point out that you've
got the abstraction levels backwards by my lights: these days I
tend to think of the class as a restricted form of role. A class is
restricted to having to provide a working interface to real objects.
Can
27 matches
Mail list logo
