t; 'DBD::Template', },
tmplss_ => { class => 'DBD::TemplateSS', },
tuber_ => { class => 'DBD::Tuber',},
uni_ => { class => 'DBD::Unify',},
xbase_ => { class => 'DBD::XBase',},
xl_ => { class => 'DBD::Excel',},
yaswi_ => { class => 'DBD::Yaswi',},
};
I mean, what's up with that? I assume DBI 1 has this for legacy app
backwards compatability, but DBI version 2 should never have to
accomodate such abhorrent computer programming practices in its core.
By having users specify the full driver class name, DBI won't have to
do any such explicit mapping.
By the way, most driver names are quite short already, so its not
like abbreviations are necessary.
-- Darren Duncan
nk that having the standard
driver namespace being outside DBI::* is an antiquated notion that
bears little resemblence to what is standard in most frameworks. All
this said, I'm not stuck on a change here, so do as you will.
-- Darren Duncan
es are good for. Perl internally
just has to know about the one number.
-- Darren Duncan
work cut for them.
BTW, my main programming project (unreleased) is a
genealogy/history/anything database type application, of an
unprecedented focus and feature set, so I've thought a lot about
these sorts of issues for being the most accurate and trustworthy
possible.
-- Darren Duncan
At 3:36 PM -0700 7/5/05, Dave Whipp wrote:
Darren Duncan wrote:
The object should not store anything other than this single
numerical value internally (smart caching of conversions aside).
I think we can all either agree with that, or dont-care it. The
internal implementation is an
bly all-singing and all-dancing,
but no-one can write a driver for it because the requirements cannot
be met by the actual DBMS that Perl + DBI needs to work with.
What you say is fair enough, but I never proposed anything impossible
or difficult; everything that I am proposing here is easy and simple.
-- Darren Duncan
Perl 6 is, so we have to consider things that are reasonable
for inclusion; even if it isn't common for native database support
now, that isn't to say that native support won't come later, and when
it does, we'll already be ready, or they'll even take what DBI does
as a cue for what they can add.
-- Darren Duncan
At 1:22 AM -0700 7/9/05, Jonathan Leffler wrote:
On 7/4/05, Darren Duncan
<<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] > wrote:
5. All details used to construct a connection handle should be
completely decomposed rather than shoved into an ungainly "data
source". Exam
how
you set up your systems, and how many levels of hierarchy there can
be with a database; eg, a server has 1+ databases, each of which has
1+ catalogs (and presumably each of those has 1+ schemas and each of
those 1+ tables and other schema objects). I will probably find it
helpful when I pla
s or various
types.
I second that. Have API methods for fetching or storing by-the-chunk
pieces of LOBs that one could not do with a traditional bind_param()
etc since the whole thing won't fit in RAM at once.
-- Darren Duncan
me from, so I can correlate them in reference
documentation?
-- Darren Duncan
any applications or drivers,
because those specify a versioned API which continues to exist as a
wrapper. See http://arstechnica.com/reviews/os/macosx-10.4.ars/4 for
what I'm talking about.
However it's done, I'm thinking something akin to that would be good for DBI.
-- Darren Duncan
ve implemented the subclass, you'll have empirical proof
of the feasibility, and, more importantly, you'll be able to port
the subclass to DBIv2, without any additional burden on DBI
developers.
I accept your challenge.
-- Darren Duncan
ar there, since Scalar seems too
specific. Likewise with NonJunction, if we can help it, because it
looks messy.
-- Darren Duncan
o -> $x {...} to be a Junction. Maybe the $x
should just be an Any and be done with it.
-- Darren Duncan
te project.
-- Darren Duncan
x27; turned on all the time
and/or being the default, likewise having 'use fatal' turned on all
the time and/or by default is also the best course of action. While
we're at it, 'use warnings' should probably be on by default too, but
this is less important than 'fatal'.
-- Darren Duncan
and
instead expect users to create objects that wrap the others instead
of subclassing them?
Assume also that it may be counter-productive for one class to expect
user code to invoke the second class on its behalf, such as if when
pair of classes is hidden behind a second pair of classes that
mediate access to them.
What are some best practices here that can be used by anyone faced by
a similar problem?
-- Darren Duncan
27;::' and
'$':
:$:
Does that conflict with anything?
-- Darren Duncan
At 3:26 PM +0100 10/22/05, Nicholas Clark wrote:
At the risk of re-enforcing my apparent optimism.
On Thu, Oct 20, 2005 at 04:02:10PM -0700, Darren Duncan wrote:
that the next best one to exploit is ยค (euro;
unicode=20AC; utf8=E282AC), and the next best is
Woah. You've just demonst
es provide
this, and is cited in Perl Best Practices as
doing so also. -- Darren Duncan
hand, perhaps something I actually want is something
like the hyper-operation but with appropriately different syntax:
['a','b'] >>~<< ['c','d']
But that it returns ['ac','ad','bc','bd'] rather than ['ac','bd'].
So is there a similarly terse way to do combinations already, and if
not then would you consider it commonly used enough to add?
-- Darren Duncan
works correctly
regardless of whether its argument came from $! or some other source,
without having to declare 'is copy' because of the possibility it is
from $!.
The big problem here is that almost any argument for any subroutine
could potentially come from $!, and it would be rediculous for them
all to be 'is copy' just to handle the possibility.
Nor is it reasonable for a caller to have to copy $! to another
variable before passing it to a subroutine just because that sub
*may* have its own try block ... a caller shouldn't have to know
about the implementation of what it called.
I welcome feedback on this issue and a positive, elegant resolution.
-- Darren Duncan
ariables, and
has nothing to do with external data repositores such as SQL
databases. Though I anticipate that one could extend or override
built-ins so that they interact with remote databases instead of
internal variables, such as with the concept of sub-classing or role
reusing or tying.
Thank you. -- Darren Duncan
At 2:54 AM + 12/15/05, Luke Palmer wrote:
On 12/15/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
I propose, perhaps redundantly, that Perl 6 include a complete set of
native
Okay, I'm with you here. Just please stop saying "native" and "core".
Everyone.
smack too much of telling Perl how to do the job.
I don't want to have to use maps or greps or whatever, to express the
various relational operations.
-- Darren Duncan
ying so.
My suggestions should not make Perl slower or more difficult to use.
They should in fact make it easier to use. And not significantly
more verbose.
Feedback?
FYI, I feel more strongly about this issue than about the other
relational things I mentioned, since the undef thing is more low
level and very pervasive, not to mention quite simple to fix.
-- Darren Duncan
ne($y)
$x == 3; # like random_one($x) == 3
The odds of two undefined values in such primitive data types being
equal is 1/Inf, which is zero.
So no 2 undefs are equal, and no undef is equal to a defined value.
You can't say what an undef equals because you don't know what value it
At 10:07 PM -0800 12/16/05, chromatic wrote:
On Friday 16 December 2005 18:15, Darren Duncan wrote:
> 0. An undefined value should never magically change into a defined
value, at least by default.
This is fairly well at odds with the principle that users shouldn't have to
bear the b
ng the
bugs introduced because such checks aren't performed in the first place. It
also allows for very strong guarantees; i.e., "I know this variable cannot
be undefined because I never assign undef to it, and the compiler would tell
me if I accessed it without assigning to it."
This is what 'use strict' should evolve toward, in my mind.
If you see 'never-assigned' and 'assigned-but-unset' to be distinct
in practical use, then maybe we need to add a method/property to all
containers that is used like .defined(), such as .unassigned() ...
but I can't say its needed.
-- Darren Duncan
At 9:30 AM + 12/17/05, Luke Palmer wrote:
On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
> Undef, by definition, is different from and non-equal to everything
else, both any defined value, and other undefs.
You said "by definition", but where is this
rograms. But like with
other strictures, this would be turned off by default in one-liners.
If the DWIM behaviour is wanted in larger programs, one can say 'no
strict undefs;' or such.
There may be remaining holes in my suggestions, but hopefully I dealt
with the worst ones from the preceeding first draft.
-- Darren Duncan
longer have to say:
eval "require $module_name;";
die if $!;
... as I do now.
I like to save string evals for when I'm actually using arbitrary
runtime generated Perl code which is in a variable.
-- Darren Duncan
First of all, I concede that features like autovivification and
undefs defaulting to the domain-qualified 'none' are fine as what
Perl does by default, so I retract any request to change this; I am
fine for these things to remain as they are and were.
-- Darren Duncan
P.S. FYI, pe
Following the discussions from 2 weeks ago, are there any plans to
update the synopsis soon regarding the $! variable? Synopsis 2 still
says that it is conjectural to whether $! is always environmental.
Thanks. -- Darren Duncan
it to say there's still the huffman
advantage of {}.
As well as the advantage of fewer changes of Perl 5 to Perl 6 porters.
-- Darren Duncan
At 3:40 PM +0100 12/22/05, Michele Dondi wrote:
On Thu, 22 Dec 2005, Darren Duncan wrote:
On a separate but related matter, I'm in the position of wanting to
do something unusual, which is create a data file format whose
content is executable perl code that defines a data structure, a
bly the point of using unboxed types is to get bleeding edge
maximum performance, and abstraction would take away from this then,
maybe. Or maybe not. But if anything bleeds through, it should be
the hardware, and not other programming languages.
-- Darren Duncan
is function is what individual classes can override.
Part way through writing this, I had a brief chat on #perl6 with
stevan (and apparently the meta-model is still quite in flux) and he
said my question was related to Larry's "class but undef" idea, and
that Larry should talk m
At 3:02 PM +0800 2/6/06, Audrey Tang wrote:
On 2/6/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
Speaking briefly, I would like it if Perl 6 provided a way for a
class (or role, or meta-class, etc) to declare that all variables
declared to be of that type are automatically/implicitly se
ve in other languages and environments when in
Perl 6.
Unless we have this feature, I would have to resort to either storing
all symbols in hashes, or hex-escaping them all to ensure useable
characters without name collisions, and that makes the resulting code
obfuscated and hard to understand; I don't want to obfuscate.
Thank you. -- Darren Duncan
I'll have to check that a test for the feature
exists, and add one if not.
-- Darren Duncan
.language show the duplicates.
This message can also test if the problem is persisting. -- Darren
Duncan
at we need is a more universal currency. I suggest gold.
So every relevant symbol name could start with
'Au' instead of '$', and an advantage of this is
that it is still easy to type on any keyboard.
-- Darren Duncan
s are improvements. -- Darren Duncan
a generally useful and
simple-ish data type to include in Perl 6 itself, while "Rosetta" is
a third-party toolkit for application building.
-- Darren Duncan
n associated value.
If such a new type is created, it could potentially be named
MutableSet, though that would break the pattern of built-in types
having one-word names, but I haven't thought of any alternatives so
far.
Thank you. -- Darren Duncan
At 7:38 PM -0700 4/27/06, Larry Wall wrote:
On Thu, Apr 27, 2006 at 01:10:05PM -0700, Darren Duncan wrote:
: 1. There doesn't seem to be an immutable bit-string type, so unless
: I read something wrong, I propose adding one.
:
: Since all built-in types have one-word names, I suggest
s possibility on some arbitrary basis like with your list
makes as much sense as taking several things larger than a bit and
saying that some are atomic while others aren't.
-- Darren Duncan
7;z'=>5); # fails
Or:
$t = tuple( set( 'x'=>Int,'y'=>Int ): 'x'=>2,'y'=>4 );
$t = tuple( 'x'=>2,'y'=>4 );
If we have an actual relation-land Tuple type, then Mapping can be
kept a lot simpler and/or the way it is now.
I'm inclined to rule out the Signature and Capture types to be used
here, since while they have some similar properties to what I'm
looking for (a Relation header could be a Signature and its body a
set of Captures), they seem function specific. But maybe you think
differently?
So, any answers to my questions and/or feedback on my ideas is appreciated.
Thank you in advance.
-- Darren Duncan
on types such as Sets.
If Perl 6 is to be the choice language of the singularity, it needs
to be easy and fast to do any common type of work with it, and
relational algebra is an extremely common kind of work being done.
-- Darren Duncan
Actually, I'll add a few more things to my reply, which should be helpful ...
At 5:11 PM -0700 5/4/06, Darren Duncan wrote:
At 10:51 AM +1200 5/5/06, Sam Vilain wrote:
>Moreover, the Relation type has these
operators that the Set type doesn't have: rename(), project(),
restr
best.
For now I'll just follow the simple path with a single Relation class
in Pugs' ext/Relation/ directory for demonstration purposes and
evaluate changes later.
-- Darren Duncan
s
reasonable "do" (appropriately restricted versions of) them; if
people have disagreements, its mainly with that sub-suggestion that I
want to know about them.
Thank you. -- Darren Duncan
a finite collection of discrete members. (Similarly, a Relation is
explicitly discrete and finite by definition.)
I assume you aren't referring to the temporal specific thing called
an interval.
-- Darren Duncan
looking for.
-- Darren Duncan
anges or collections. Temporal or
spacial data in common use today is just too complicated and
non-generic, I think.
(Whereas, the existing built-ins, and relations, are very generic and simple.)
-- Darren Duncan
x; has Real $y; };
subset Interval of Range where { all( .items ).does(Real) };
-- Darren Duncan
At 6:06 PM -0700 5/6/06, Darren Duncan wrote:
You can do it simply, kind of like this:
class Point { has Real $x; has Real $y; };
subset Interval of Range where { all( .items ).does(Real) };
Er, you should read 'Real' as 'Num' (I originally meant Rational,
which no
sides of the hyper-operator?
So I would appreciate if the S03 examples could be explained as to
why they would work, or alternately please replace 'Bag' with 'Seq'.
Thank you. -- Darren Duncan
Er, I meant to say "subtracted" where I said "added". -- Darren Duncan
At 4:11 PM +1200 5/23/06, Sam Vilain wrote:
Darren Duncan wrote:
$bag1 >>-<< 1; # Bag(2,7,[1,Seq(8,2)],7)
$bag2 >>-<< (1,1,1,1); # probably the same
> $bag3 >>-<< (1,1,2,1); # ?
Bag's won't .does(Array) or .does(Coll
l of Synopsis
12.
I'm fairly sure the "self" syntax is invalid.
Moreover, S12 explicitly says that Perl 6 has no barewords, save
package names in specific circumstances.
-- Darren Duncan
At 1:45 PM +1000 5/29/06, Stuart Cook wrote:
On 5/29/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
There are many places where the bareword "self" is used, whereas I
believe the current syntax is "$?SELF" for the same thing, and has
been for awhile.
Actually, I s
cases of multiple processes or threads, but they can
easily be added onto what I stated, which is also useful when there
is just a single process with a single thread.
-- Darren Duncan
ntee successful completion before it
returns control, the invoker should know that vs when completion is
guaranteed.
In other words, an invoker of an op should know whether the op is
ACID compliant in all parts of its operation or not.
-- Darren Duncan
eemed to me that the enum seemed to be
operating like a C enum, where every value corresponds to a native
integer, so perhaps "buf" is more appropriate. Or alternately, we
should see "Int" and "Str" here.
-- Darren Duncan
me};
Will this work to make a Set that can only have non-empty strings as members?
9. If you declare a parameter of a type that does Foo, and you pass
an argument that is a different type that does Foo, but neither of
them is of type Foo, will the compiler accept the binding (though it
may fail at runtime)?
Thanks. -- Darren Duncan
of a string-join. -- Darren
Duncan
At 6:25 PM -0700 7/8/06, Darren Duncan wrote:
At 8:32 PM -0400 7/8/06, Joe Gottman wrote:
I have one minor comment about join. You should specify its behavior when
it is passed an empty list. Does it return undef or the empty string?
I think it makes the most sense for it to return an empty
else should be
used instead, something that isn't invoked when working with hash
keys.
I may have forgotten to raise something else, but there's that for now.
-- Darren Duncan
the immutability, and all objects of the same
class would be the same in that respect. Incidentally, your Currency
example would likely be an immutable type. -- Darren Duncan
recommend having negated versions of all these various types of
equality tests. Eg, !== for ===, nev for eqv, etc. They would be
used very frequently, I believe (and I have even tried to do so), and
of course we get the nice parity.
-- Darren Duncan
I think that Jonathan meant for his reply to my message to go to the
list, so I am including it in its entirety, in my reply.
At 11:23 PM -0700 7/13/06, Jonathan Lang wrote:
Darren Duncan wrote:
Jonathan Lang wrote:
So the purpose of === is to provide a means of comparison that doesn&#
sary. The above-stated rule would still stand for any resources
managed by Perl itself.)
-- Darren Duncan
At 12:30 AM -0700 7/14/06, Darren Duncan wrote:
If $a === $b means what I think it does, then I believe that a
not-premature implementation optimization of === would be that it
always $a := $b if it was returning true, so that any future === of
$a and $b or aliases thereof could short-circuit
At 9:22 AM -0700 7/14/06, Dave Whipp wrote:
Darren Duncan wrote:
Assuming that all elements of $a and $b are
themselves immutable to all levels of
recursion, === then does a full deep copy like
eqv. If at any level we get a mutable object,
then at that point it turns into =:= (a trivial
matter whether you have $x and $y or $y and $x, the result is the
same. So you can use whichever order you want without it needing to
be coded for. -- Darren Duncan
At 12:55 PM -0700 7/14/06, Larry Wall wrote:
On Thu, Jul 13, 2006 at 10:56:59PM -0700, Darren Duncan wrote (edited):
: Now, I didn't see them yet anywhere in Synopsis 3, but I strongly
: recommend having negated versions of all these various types of
: equality tests. Eg, !=== for ===, !eq
it is just like ||, which takes any kind of values as
input, but that the latter returns the first actual value of the
first 2 arguments, while the former doesn't. The || comparison
suggests that maybe ?| belongs with the tight-or operator set rather
than bitwise. It might help if some of this was clarified. Part of
the confusion though is that ?| isn't in the operator precedence
table.
-- Darren Duncan
$z.aliases -> $z_alias {
$z_alias := $y;
}
# now $x and $y and $z all point to 'bar'
Unless something like this could be available for use, it would be
impractical to implement run time folding just using := since we
could end up in a tug of war situation if folding comparisons between
pairs drawn from a pool of all equal elements were not done in
exactly the right sequence.
-- Darren Duncan
result elements and produces derived ones.
-- Darren Duncan
taking a single parameter of type Dog.
Typo: Shouldn't that last line better say either "having a single
parameter" or "taking a single argument"? -- Darren Duncan
o be the
best compromise.
So, stepping aside from any "it ain't broke" arguments in the favor
of Str, is there anything about the name Text that makes it a worse
or better candidate in regards to specificity or ambiguity in your
mind?
Or alternately, are there any other names which might work better
than Str for specifying character data?
-- Darren Duncan
At 5:25 PM -0700 8/8/06, Darren Duncan wrote:
I'm wondering if it would not be inappropriate to change the name
Str to something more descriptive of its content within the
historical or current wider context.
For example, would the name Text be any worse? In my mind, that is
less ambi
le once created. There would exist
operators to convert between a Blob and various Str representations
for transmission of the data through a text-only medium, such as
hexadecimal or octal etc.
Truly, a Blob type should be a very natural addition, and a final
missing link in some respects.
Thank you in advance.
-- Darren Duncan
ated like Num or Str
etc in that === always compares them by value. -- Darren Duncan
I never thought to ask for.
And of course, the actual implementation is a lot better, with all
the various command-line options|args being mapped to normal Perl 6
args in an easy to understand and powerful way.
The default USAGE() sub was a great idea too.
I am SO going to use this.
-- Darren Duncan
it in the open with the same separators as
what is used to separate the authority from the version etc.
-- Darren Duncan
rsions they run
under.
-- Darren Duncan
At 10:35 AM -0600 8/13/06, David Green wrote:
On 8/8/06, Darren Duncan wrote:
I thought your reasons made sense, and would be happy with a "Text"
type, although I don't especially object to "Str" -- as you say,
it's probably good enough given ordinary progra
oint in time
when it executed.
It is important for some applications to distinguish whether the
result of an equivalence test will be valid eternally or not, and
hence we have multiple analagous types and multiple equality tests,
where pairwise they distinguish eternally vs snapshot. We can say
exactly what we mean, and it is unambiguous, which is a GOOD thing.
-- Darren Duncan
At 11:42 AM +0300 8/16/06, Markus Laire wrote:
On 8/16/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
The difference between === and eqv is that, if you have 2 symbols, $a
and $b, and $a === $b returns true, then that result is guaranteed to
be eternal if you don't assign to ei
At 11:16 PM -0600 8/16/06, David Green wrote:
On 8/15/06, Darren Duncan wrote:
At 2:51 PM -0600 8/15/06, David Green wrote:
[...]
You are right, but we have both Seq and Array types, so depending
which one you use, you want either the === or eqv operators to do
what you want. There is no
lared in
a file not named "Mammal". Even then, I don't know if this implicit 'use'
action would be a good idea, as it may be a source of bugs. -- Darren Duncan
;t subclasses.
4. We need to be able to programmatically define accessors and
constructors for new classes/classless-objects too, unless those come
for free when we declare attributes public-ish.
--
In closing for now, I imagine that a lot of this stuff is connected
to the meta-model, though doing it well will have clean support in
the language syntax as well.
Feedback is appreciated.
Thank you. -- Darren Duncan
ss, so
people can choose how it works.
-- Darren Duncan
hat the
relational analogy of an in-memory Hash is built-in to Perl, and any
extensions that make it tied to something external like a disk be
language extensions / CPAN modules; all Perl 6 iteself has to do is
make it easy to attach such extensions, and I think it more or less
does so, save edge cases to hash out.
-- Darren Duncan
much more understandable as to what it does.
It should also help me to implement some aspects of Set::Relation, maybe.
Thank you for this update.
-- Darren Duncan
u can see, there is a repeated inconsistency here as to the name
of this meta-object method. While it is possible that the actual
meta-object API hasn't been decided on yet, the stand-in Synopsis
examples should at least be consistent. -- Darren Duncan
1 - 100 of 477 matches
Mail list logo
