About RFC 271: pre/post handlers

2001-01-24 Thread Branden
: 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

Re: About RFC 271: pre/post handlers

2001-01-25 Thread Branden
myself clear with my approach, I may eventually rephrase it... Thanks, Branden.

Re: About RFC 271: pre/post handlers

2001-01-25 Thread 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 as strange as $_[-1], why don't we have only one

Re: JWZ on s/Java/Perl/

2001-01-29 Thread Branden
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

Re: JWZ on s/Java/Perl/

2001-01-29 Thread Branden
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

Re: JWZ on s/Java/Perl/

2001-01-30 Thread Branden
we put into locks, the more we enforce programmers to be conscient about race conditions in multi-threading. - Branden

Re: Why shouldn't sleep(0.5) DWIM?

2001-01-30 Thread Branden
!), 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

Re: Why shouldn't sleep(0.5) DWIM?

2001-01-30 Thread Branden
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 minds. Just because UNIX decided that its sleep function would return an int value, doesn't mean we have

Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Branden
e 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

Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Branden
won't ever be passed to the syscalls sleep(3) and alarm(3). Perl will probably block that instance of the interpreter internally and do some other stuff. It will probably use its internal clock to measure the time to unblock it, and that clock will probably have sub-second precision. - Branden

Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Branden
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

Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Branden
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

Re: assign to magic name-of-function variable instead of return

2001-02-05 Thread Branden
o the user. - Branden

Re: assign to magic name-of-function variable instead of return

2001-02-05 Thread Branden
o the user. - Branden

Re: Really auto autoloaded modules

2001-02-05 Thread Branden
(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

Re: Really auto autoloaded modules

2001-02-05 Thread Branden
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

Re: assign to magic name-of-function variable instead of return

2001-02-05 Thread Branden
for the reader. :) Well, try that on strict 'subs'... - Branden

Re: assign to magic name-of-function variable instead of return

2001-02-06 Thread Branden
. 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

Re: assign to magic name-of-function variable instead of return

2001-02-06 Thread Branden
, 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

Re: Auto-install (was autoloaded...)

2001-02-08 Thread Branden
, 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

Re: Auto-install (was autoloaded...)

2001-02-08 Thread 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 supporting this would be neat. I

Closures and default lexical-scope for subs

2001-02-08 Thread Branden
$x = shift; parent_sub's $x; return $x + $n; }; return $increment; } Comments? - Branden

Re: Auto-install (was autoloaded...)

2001-02-08 Thread Branden
. 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

Re: Auto-install (was autoloaded...)

2001-02-08 Thread Branden
). 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

Re: Auto-install (was autoloaded...)

2001-02-08 Thread Branden
b. I guess their file format is a disguised .tar.gz, right? - Branden

Re: Auto-install (was autoloaded...)

2001-02-09 Thread Branden
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

Re: Auto-install (was autoloaded...)

2001-02-09 Thread Branden
ndled 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

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-09 Thread Branden
unt 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

Re: Auto-install (was autoloaded...)

2001-02-09 Thread Branden
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--+-+-+-+ - Branden

Re: Auto-install (was autoloaded...)

2001-02-09 Thread Branden
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

Re: Auto-install (was autoloaded...)

2001-02-10 Thread Branden
in a determined format) an utility to convert a package from one format to another. Otherwise, developer's life would be harder... - Branden

Re: Auto-install (was autoloaded...)

2001-02-12 Thread 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 decompressing the whole archive, what

Re: Auto-install (was autoloaded...)

2001-02-12 Thread 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 decompressing the whole archive

Re: Auto-install (was autoloaded...)

2001-02-12 Thread Branden
that we'd like them to have the same interface, so that we can use one or another with the same code. - Branden

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-12 Thread Branden
bject 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

Re: Auto-install (was autoloaded...)

2001-02-12 Thread 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). You also forgot the "Is Vapo

Re: Auto-install (was autoloaded...)

2001-02-12 Thread Branden
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

Re: Auto-install (was autoloaded...)

2001-02-12 Thread Branden
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

Re: Auto-install (was autoloaded...)

2001-02-12 Thread Branden
e should standardize on one... - Branden

Re: Auto-install (was autoloaded...)

2001-02-12 Thread Branden
th the par attached as __DATA__ or something. See my solution above. - Branden

Re: Auto-install (was autoloaded...)

2001-02-12 Thread Branden
W, this plan would make it painful to do with perl5 setups, since they commonly have odd dir structures. This is something that should be redesigned 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

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-14 Thread Branden
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

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-14 Thread 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. Basicly, delete should DESTROY the arg

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-14 Thread Branden
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

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-14 Thread Branden
net/theorb/ - Branden

Re: Garbage collection (was Re: JWZ on s/Java/Perl/)

2001-02-14 Thread Branden
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 problem, I think we can deal with that when we try to allocate a resource and we get an error

defined: Short-cutting on || with undef only.

2001-02-15 Thread Branden
$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

Re: RFC on Coexistance and simulaneous use of multiple module version s?

2001-02-15 Thread Branden
rsion of the module associated with OtherNamespace ??? What if several modules put things in a common namespace ? - Branden

Re: Closures and default lexical-scope for subs

2001-02-15 Thread Branden
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

Re: Closures and default lexical-scope for subs

2001-02-15 Thread 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 used to say that a specific variable or a list of them

Re: Closures and default lexical-scope for subs

2001-02-15 Thread Branden
' you said it has. - Branden

Re: Closures and default lexical-scope for subs

2001-02-15 Thread Branden
), writing one or two more lines isn't expensive at all... - Branden

Re: Closures and default lexical-scope for subs

2001-02-15 Thread 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 the proposal is not a good one. There was more

Re: End-of-scope actions: do/eval duality.

2001-02-15 Thread Branden
[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 have the behaviour of not dying and setting

Re: Closures and default lexical-scope for subs

2001-02-16 Thread Branden
) = @_; or even my($a, $b, $c) = @_; ## current syntax keeps working. - Branden

Re: Closures and default lexical-scope for subs

2001-02-16 Thread Branden
pointless changes with perl5. If this makes `my' DWIM, I think it's not pointless... - Branden

Re: Closures and default lexical-scope for subs

2001-02-16 Thread 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 language that parallel its use. Well,

Re: Closures and default lexical-scope for subs

2001-02-16 Thread Branden
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

Re: Closures and default lexical-scope for subs

2001-02-16 Thread Branden
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

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

2001-02-16 Thread Branden
be there Perl jokes?) Who writes this kind of code anyway? - Branden

Re: Closures and default lexical-scope for subs

2001-02-16 Thread Branden
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

Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

2001-02-16 Thread Branden
). 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

Re: Closures and default lexical-scope for subs

2001-02-16 Thread Branden
, and we shouldn't discuss taste. - Branden

Re: The binding of my (Re: Closures and default lexical-scope for subs)

2001-02-16 Thread Branden
rl, what also makes Perl a little easier to use. (Note I didn't say `every *other* function', I *know* `my' isn't one.) - Branden

s/./~/g

2001-04-23 Thread Branden
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

Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-23 Thread Branden
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

Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-23 Thread Branden
.$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.

Minimalistic Perl 6 Language

2001-05-03 Thread Branden
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