one, but I list it down here for
completion:
: sub abc_handler {
: do_pre_handler(@_); # pre part
: my $result = $_->(@_);
: do_post_handler($result);
: return $result;
: }
: push_handler(\&abc, \&abc_handler);
Well, what you think of it? Does it have disadvantages I'm not aware of?
Branden
only on the behaviour
the superclass attaches to the same method!
I think I didn't make myself clear with my approach, I may eventually
rephrase it...
Thanks, Branden.
Garrett Goebel wrote:
> From: Branden [mailto:[EMAIL PROTECTED]]
> >
> > I was reading RFC 271 and thinking about this pre/post
> > handler thing. Why instead of having 2 subs, one for
> > pre and other for post condition, and having to deal
> > with things a
ts he goes about it. I actually didn't read
it, but I guess he means he prefers Java to C++. This
point I disagree. Of course, C++ has no GC, which is a
good thing, but you can always fake it with Refcounts,
which is much more efficient, and easily feasable with
C++. And at least they didn't chop from you templates
and operator overloading, which could do Java a usable
thing. At least I could then have a list of integers,
instead of the verbose code above!
- Branden
have threads, you have to say
explicitly if you want anythinig to be shared. And if you explicitly
share something, then you should care the locks by yourself.
At least, that's my opinion.
- Branden
robably the hardest type to spot,
hardest to reproduce kind of things that lead to bugs. I think the less
magic we put into locks, the more we enforce programmers to be conscient
about race conditions in multi-threading.
- Branden
point continues, int(time()) solves p52p6 problem!),
RFC 73, on making all built-ins return objects, which would do the
stringifying thing or even allow with and without fractions in one
object, and RFC 48, on changing localtime() and gmtime(), 'cause
maybe time() will go with them too!
- Branden
that
are present only in *non-local* variables, and take care of holding
some locks for every operation that is made against that variable.
This way shared data structures get protected.
- Branden
r borked. Please investigate.";
: # in a logfile, the clarity argument is even more valuable...
Well, at least that's what I think about time. This change wouldn't break
compatibility, and changing the way we think about this function is a
healthy thing for our programmer mind
ary measurement is
> absurd. It might makes sense to have some other functions giving units
> since some point in the past next to time() though.
More than one function to do the same thing is A Bad Thing, IMO. It only
causes confusion.
If a change of mind when writing new software is too much a burden, then,
I say it again, we should stick with perl5! As Jarkko always quotes:
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
If old code and old-code thinking are the only thing that prevents us to
change time() or move it out of CORE, then I believe we should do it yes!
- Branden
nd that clock
will probably have sub-second precision.
- Branden
oing this, like AUTOLOAD is for modules, would
be a good thing. Whenever an inexistent sub is called and it cannot be found
in existing packages and by package's AUTOLOAD's, this special sub is called
and it can auto-load packages that provide such functionality. Then there
would be a generic way to do such things.
- Branden
a bad thing.
I share your thought. But I proposed a new name for people that think that
``this would confuse UNIX users, that relate Perl's time with UNIX C's
time''.
Having the same name and modifying the semantics is more appropriate, IMO.
- Branden
esult value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
esult value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
g/modules/Bar';
use Baz URL => 'ftp://my.local.domain/pub/share/perl-modules/Baz', VERSION
=> 2.0;
This way, Perl could automatically fetch and install modules (supposing
module install is not so hard as now, involving makefiles, and such...). And
this could also be used to identify interfaces. That's only an idea, but I
think it can lead to good things.
- Branden
Piers Cawley wrote:
>"Branden" <[EMAIL PROTECTED]> writes:
>> Of course, C++ has no GC, which is a good thing, but you can always
>> fake it with Refcounts, which is much more efficient, and easily
>> feasable with C++.
>
>Err... current research sho
w your first proposal would save keystrokes, by replacing
`return $x;' with `MyReallyLongishAndBloodyIdiotSubName = $x; last
MyReallyLongishAndBloodyIdiotSubName; # must type this to get out of the
sub'. Anyway, I always recommend to learn to type fast, it ain't hard (just
kidding... ;-)
- Branden
to handle the case in which the module is not found,
tipically to create stubs to the subs/classes the module would provide...
> * What happens when the requested version isn't found?
same as above.
If that's a common desire, I volunteer to help writing the beast. Can even
start it on Perl 5, and then convert it with p52p6. This way everyone can
see it and make critics before shipping it with Perl 6.
- Branden
> left as an exercise for the reader. :)
Well, try that on strict 'subs'...
- Branden
e nifty tool from Internet for a
quick job, I don't want to go in the complexities of MakeMaker, Makefiles,
not to mention compilers, which I don't have access on Win32 (yeah, I have
Cygwin, but I never compiled Perl with it...). I think easy
access/downloading/building of external modules is a must to make Perl more
popular.
- Branden
) is. It's
rather explicit, and is very clear about what is done. Using a (\@)
prototype on DirectBubbleSort would be ok too, since its name says right
what it does and everybody likes some vanilla syntax. But making it
@SomeList = DirectBubbleSort is the most error-prone thing I see! Nobody
will get it right on first use...
- Branden
.
> > Eh, I don't think that bad memory, or a bad variable naming scheme
> > justifies this new feature.
> A new feature doesn't need that much justification. And nobody is
> advocating getting rid of "return".
Yes it does. Otherwise, we get even more bloated than now!
- Branden
-loading of the same modules from Internet, if they are pretty
obfuscated or are in byte-code form. Only a sandbox or something like that
can assure security in either case.
- Branden
Michael G Schwern wrote:
> On Thu, Feb 08, 2001 at 12:07:18PM -0200, Branden wrote:
> > The issue is actually not auto-downloading modules and their
prerequisites,
> > but actually packaging several scripts and modules in one file, so as
Java's
> > jar do. I think sup
-scoped variables by default:
use scope 'subs';
sub make_incrementer {
$n = shift;
$increment = sub {
$x = shift;
parent_sub's $x;
return $x + $n;
};
return $increment;
}
Comments?
- Branden
applications would be actually distributed on the
`.noarch' kind of par archive, to contrast the `.src' kind.
Did I miss something here? Is it just me, or you also think this
(deploy/install) is essential for a language be used by `layman-users', and
not only JAPHs.
- Branden
t zip?
Is it ported to all platforms Perl currently runs on? Is there a Perl module
for handling zips?
- Branden
7;t solve the problem for scripts/programs).
Anyone of ActiveState there? Can't we adapt PPM so that it handles what's
needed? Or is it too different from what we want? Does it use zip or
tar/gzip or other?
- Branden
I'm writing a PDD on the subject, as suggested by Dan, and I intend to post
it by tomorrow. In the lack of a better list, I think we stick
with -language. If someone can suggest a better one, please do it.
- Branden
ead about it in
the web. I guess their file format is a disguised .tar.gz, right?
- Branden
n the PDD. Anyone has a suggestion on something to add?
Other important issue I don't know yet: Is there an Archive::Zip module for
Perl? How cross-platform is it? Can we bundle it with Perl (licensing
issues)? Is it stable? Will it give us the support we need (access to
individual files in the archive, and the ability to `fake' them as real
files through tied filehandles)?
- Branden
n";
print $c;# also prints nothing
--
*c = \$b;
*b = \$a;
$a = "foo\n";
print $c;# also prints nothing
I guess that demonstrates that aliasing is a wild beast and using it for
more than two variables is probably a good way to get in trouble...
- Branden
would just pass the bytes
through. This is what should probably be used for zip. If you mean the
uncompress-on-the-fly thing I think it would be handled like source filters
are today. In Perl 5.7 you can even have a source filter that decompresses a
.gzipped script and runs it, by using a source filter. I believe zip could
be handled by this also in 5.7. Perl 6 will certainly improve this area very
much.
- Branden
correct spell and grammar would be very
appreciated.
- Branden
(cut here) ---
PDD: `par' -- The Perl Achive
1. Introduction
`par' stands by `Perl Archive'. It's a way to provide deploy and
installation of Perl programs/scripts
so of p5p where
> Alan's trying to plug a batch of perl memory leaks to see how well the
> refcount scheme seems to be working now...
Yeah, I know that... But I actually think this is because Perl 5's
implementation of refcounting is quite messy, specially when weakrefs are in
the game.
- Branden
n really doubt... Breakfasting? ;-)
> I agree with Branden that the inheritance semantics is screwy.
> I think DesignByContract contract enforcement is best done with
> a parameter typing system of some kind (as in C++). Proper
> objects don't get into invalid states (unless you
ctually 10 times it
needs to be? (if it were even _possible_ to pack all the data without
fragmentation problems)
- Branden
| Yes |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
+--+-+-+-+
- Branden
of the same thing only to satisfy users that use
different formats').
I think we should go for `standard' rather than `flexible' on this one.
Of course we still can change the file format, if someone isn't happy about
zip. That's the advantage of discussing it before making it: it's not here
for we to regret about it...
- Branden
he user could
request an archive in a determined format) an utility to convert a package
from one format to another. Otherwise, developer's life would be harder...
- Branden
John Porter wrote:
> Branden wrote:
> >
> > For example, with tgz it would be complex to deal
> > with running without extracting,
>
> What? tar -z not good enough for you?
>
The problem is that we cannot access individual files inside the archive
without decompr
all .tar.gz.
>
I actually don't believe the modules already on CPAN will work directly,
since they'll probably have to go through p52p6 translation. And I don't see
any problem in supporting the old approach to installing modules, since it's
mainly manual and requires almost no support from the programs.
- Branden
Jarkko Hietaniemi wrote:
> On Mon, Feb 12, 2001 at 12:36:53PM -0300, Branden wrote:
> > The problem is that we cannot access individual files inside the archive
> > without decompressing the whole archive, what is possible with .tar (not
>
> I do not see a huge problem in de
define the
Archive::* implementations for Perl6, possibly stating that we'd like them
to have the same interface, so that we can use one or another with the same
code.
- Branden
you need to do a "is it an object with a
> DESTROY" check at block boundaries.
>
Only because the type is static, I don't think they wouldn't be references.
my $foo = new Baz();
{
my Baz $bar = $foo;
};
# DESTROY should be called on the object ref'd by $bar ?
# It's still ref'd on $foo !!!
- Branden
[EMAIL PROTECTED] wrote:
> On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
> > I put together a comparison table between par and rpm/jar.
>
> You forgot deb, which I'd *much* rather deal with than rpm (if only
> because I can point apt and dselect at CPAN).
another features, and make benchmarks
with all proposed formats. And probably `p52p6' can be used to translate it
to Perl 6 and include it in Perl 6 distribution, cutting much work (and
time) when Perl 6 is ready.
- Branden
If not, where should we be discussing
it?
>
> [EMAIL PROTECTED] anyone?
>
If someone cares to create this list? It should probably be
[EMAIL PROTECTED], because I believe the main focus is on shipping it with
Perl 6, althought I think we'll probably have a preliminary version on Perl
5.
- Branden
bly help me with this, if that's OK with you. Could
you
> > send me some text/URLs saying how it works so that I can figure out one
way
> > to do it and include it in the PDD.
>
> Oh, I'm the last person to ask about crypto. I don't even know how to
> use pgp. I just peeked into a jar and saw how they did it.
Are there already modules that handle this (RSA/IDEA/...) ? Perhaps we'll
also want them to share the same interface so that we can do it flexible as
well... For this one I don't know if we could support different key formats
or if we should standardize on one...
- Branden
The problem
> of having Perl but not pun.
Won't be a problem with Perl 6.
> That's simple enough, par can build an
> archive with a minimalist version of pun with the par attached as
> __DATA__ or something.
>
See my solution above.
- Branden
igned for Perl 6. And I think this
discussion goes along with the one about `par', since these directory
structures exist mainly for installing extensions on them...
- Branden
ot;bar";
}
I die with "foo" or "bar" ? Why is this the right behaviour? Any sample code
that shows why this should be done this way and not the other?
Thanks,
- Branden
loyment of Perl itself and Perl programs & modules.
- Branden
st to deal with this is set a flag if
the object was already DESTROYed. Then if any other tries to use it, it
raises an exception (dies) with a message about ``This object was already
DESTROYed.''. This flag could be used also to signal to the GC system that
the object already got its DESTROY method called, and it shouldn't be called
again. Just an idea, but...
- Branden
James Mastros wrote:
> On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> > Also, I think it would be valid for the programmer to explicitly say ``I
> > would like to DESTROY this object now'',
> I'd think that an extension to delete is in order here. Bas
licitly destroy an object, for
better (and sooner) resource disposal. The programmer wouldn't have to do it
(and wouldn't do it most the time), but if he knows he uses many resources
and he would like to be nice, he *could* do it (not meaning he would have to
do it either...).
- Branden
ames Mastros
> --
> "All I really want is somebody to curl up with and pretend the world is a
> safe place."
> AIM: theorbtwo homepage: http://www.rtweb.net/theorb/
>
- Branden
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > [snip about DESTORY predictablity not being neccessary]
> > You're probably right about that, Branden. Quite nice, but not
neccessary.
> Hmm, I'd have to say that predictability is very, *very
handles ASAP. OTOH, if you're writing an
application that only opens one file and does a lot of processing over it,
you simply wouldn't care and let it be freed whenever the GC collects its
memory.
> At 10:12 AM 2/14/2001 -0300, Branden wrote:
> >If resource exhaustion is the proble
; form. do FILE behaves just like eval() (except it reads its data from a
> source file), while do BLOCK doesn't. Neither.
>
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the behaviour of not dying and setting $@ ?
- Branden
Perl 5, it would be written `defined($x) ? $x : "N/A"', but this has the
problem that $x is evaluated twice, so it doesn't work if instead of $x we
have a function call (or even if $x is tied...).
- Branden
odule, MyModule::OtherModule, etc. and mainly when `use
MyModule' creates namespace OtherNamespace (that has nothing to do with the
name `MyModule'). How will Perl know what's the version of the module
associated with OtherNamespace ??? What if several modules put things in a
common namespace ?
- Branden
I only
think it would probably be useful for some of us, and that only adding a new
`scope' pragma wouldn't hurt anybody, while possibly helping some. And it
wouldn't be much work to do either, since mostly everything that can be done
with it can be almost directly translated in something that can be done
without it (but hey, let's put the burden on translate it to the compiler,
since it's what it does anyway!).
Sorry again to bother you with this issue again, but I actually think it's
worth trying it.
- Branden
Jonathan Scott Duff wrote:
> On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote:
> > I propose the introduction of two new keywords (just like `my' and
`our')
> > for specifying a different scope: `global' and `outer'. `global' would
be
> > use
;s AAAD for sure!
I never said `our' should affect the variables inside the block! I said this
was the *main* problem in the discussion of RFC 64! Having `our' (or
anything) outside the scope change the scope of things is a very bad idea.
It's clear it ends with all the purpose of it.
>
> I have to disagree with you.
>
Read it again, and see if it has problems or not. Note again, I'm not asking
you to use it, or even like it. I'm only asking if it has the ``far more
serious problems than it purports to solve'' you said it has.
- Branden
y don't think making one of this things
default would be good, because it would make one-liners and small quick and
dirty scripts some harder to write. For longer scripts and modules (that
already are many lines long), writing one or two more lines isn't expensive
at all...
- Branden
John Porter wrote:
> Branden wrote:
> >
> > Well, I checked the archives, and I found that the discussion begun in
> > http:[EMAIL PROTECTED]/msg01441.html
>
> That thread was rather tame; even so, I believe the end result,
> if one can be deduced, is that
<[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > little too much not-orthogonal? Why don't we require `eval { do FILE }'
to
&
ged. Its way of working is already in
our subconscients. Changing it would be probably bad. But it surely isn't
consistent with the rest of the language.
- Branden
f
(my $a, $b, $c) = @_;
or even
my($a, $b, $c) = @_; ## current syntax keeps working.
- Branden
hould result in $c==3, which is the
expected.
Both ways are possible though.
- Branden
k like a function, so it isn't.
>
> Ah, more pointless changes with perl5.
>
If this makes `my' DWIM, I think it's not pointless...
- Branden
Bryan C. Warnock wrote:
> On Friday 16 February 2001 07:36, Branden wrote:
> > But it surely isn't
> > consistent with the rest of the language.
>
> It's consistent with "our" and "local", which are really the only other
> things in the langua
I said:
> Anyway, I don't see why `local' (and `our' and `my') should bind more
> strongly than , and = . They are list operators, they should behave the
same
> as those.
>
Actually, they *look like* list operators, they should behave like those.
> - Branden
>
>
roduct,
I think that's why we discuss it here.
> - you don't make any of these decisions arbitrarily.
That's why we argue about it. It's not about changing something just for the
fun of it. We must see where it's better, where it's not, if we would pay
the price for changing it, if it's worth it. I'm not proposing it because I
like changes, but I also don't the not DWIMness of some things of Perl.
- Branden
ocal($,),my($c)) = @_;
What is it, anyway? A joke? (There's Perl poetry, why can't be there Perl
jokes?) Who writes this kind of code anyway?
- Branden
7;'. Please just think about it and tell me
in which cases `` 'my' having higher precedence than comma is signficantly
more useful than if it had a lower precedence'', instead of just saying
``Let's all just acknowledge that fact''. I really can't find one way in
which the current behaviour is more `useful'!
- Branden
they're different (one is compile-time, other runtime, and much more
differences). But both (potentailly) receive a list of arguments. With
`print' (or any other function) I don't need parenthesis if I don't want to
put them (and I almost always don't want them). Why with `my' I do need
them? Why don't these behave the same?
- Branden
ey both get lists (agreed, different lists, `my' needs a list of
variables) and they both should behave the same when lists are given to
them.
>
> This would upset the entire structure of perl's usefulness.
>
You're completely right. Messing with `,' and `=' is a bad idea.
> --
> John Porter
>
> You can't keep Perl6 Perl5.
>
>
- Branden
AAD. Is there any?
I hope I can calm things a bit here, since I'm sure we'll never agree on
what's better, this is too much a matter of taste, and we shouldn't discuss
taste.
- Branden
is
around `my's variables, what also increases readability.
Think about it, the change isn't really big. The only differences are the
necessary parenthesis on usage of `my' in the middle of a list of arguments
and the fact of `my $a, $b, $c;' DWIMs, what is a big win, IMHO. Beginners
would know they can use `my' the same way they use every function in Perl,
what also makes Perl a little easier to use. (Note I didn't say `every
*other* function', I *know* `my' isn't one.)
- Branden
eat things Perl
doesn't... But when I saw it's Java-like syntax, I thought: Forget about
it! Perl syntax rules!
The bottom line is: please don't change the syntax, unless it's
unavoidable. It will cost many time of reading code until finding bugs
because of operators that used to work and don't work anymore...
- Branden
e it is pretty good the way it is!
>This is something to watch out for, not something that should decide
>Perl 6's design for paranoia's sake. I know that I am not the only one
>that loves Perl first and foremost for its syntax.
I am another one that loves Perl first and foremost for its syntax.
>Change too much and
>you're bound to drive some people away. Especially if these changes are
>inconsistent with other languages.
IMO, consistence with other languages doesn't matter.
>My conclusion: I say we do ". and +" or neither.
My conclusion: Let's not fix what is not broken.
- Branden
ne-liners know the value of $ugly.$and.$nasty.$things.
Anyway, any behaviour that would break my script if I add/remove whitespace
of is nasty.
- Branden
"Let's not fix what isn't broken."
ou cause a whole bunch of JAPH's to relearn lots. And
> > then, these people might be prompted to say "Hey, if I have to relearn
> > all this, let me check out some alternatives."
>
>Well they certainly won't run to Java.
>They might look at Pythong -- but there they'll find syntactic
>peculiarities that make Perl6 look like Ada.
s/Perl6/Perl5/;s/Ada/Befunge/;$_.=' ;-)';
- Branden
about these language issues. Please,
don't flame on me because of this. It's only my opinion, and I think
many people think different than this (actually, my opinion is all based
on this fact). I also don't expect it to be accepted or agreed by all, I
only wanted to share my thoughts about it, so that maybe someone can see
the subject on a different, new point of view.
- Branden
87 matches
Mail list logo
