On Wed, Jul 13, 2005 at 17:23:28 -0600, John Williams wrote:
> 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 databas
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 I
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
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, it
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 disp
(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 objec
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 poin
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 impressi
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.
On Jul 13, 2005, at 6:16 PM, chromatic wrote:
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
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
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 necessaril
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 ma
On Wed, Jul 13, 2005 at 05:48:47PM +0200, Ingo Blechschmidt wrote:
: If you wanted the compiler to parse SomeOtherModule.pm using Ruby's
: grammar, you'd have to write:
:
: use Grammar::Ruby;
: reuse SomeOtherModule
You'd also have to write "reuse", because we're not going to write it
for
On Jul 13, 2005, at 4:35 PM, chromatic wrote:
On Wed, 2005-07-13 at 16:07 -0400, David Storrs wrote:
My understanding is that a Role is an abstract (i.e. cannot be
instantiated) blob of methods and, possibly, data. The purpose of a
Role is to paste it into a class--in other words, a Role is
On Wed, 2005-07-13 at 16:07 -0400, David Storrs wrote:
> My understanding is that a Role is an abstract (i.e. cannot be
> instantiated) blob of methods and, possibly, data. The purpose of a
> Role is to paste it into a class--in other words, a Role is a not a
> type, it is a part of a type.
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, pos
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 time
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 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
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 {
submethod
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
-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": h
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; perl6-langu
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
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 mak
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 invo
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
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:
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=ferragina
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 multimethod/mult
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 'least-inherit
Mark Reed asked:
OK, sorry if I missed this in an earlier discussion. For purposes of
calculating this Manhattan distance, I gather that we're treating lists of N
arguments/parameters as points in N-space. I further assume that the
monoaxial distance between a parameter coördinate and the corr
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, Hope
33 matches
Mail list logo