Chaim Frenkel wrote:
>
> > "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
>
> NW> Also, how about just $@->id? Shorter and I would argue the "unique_" is
> NW> really redundant (id's are usually unique, hence the name
> NW> "identifiers").
>
> Not really.
>
> Consider: Chaim is an identi
> "NW" == Nathan Wiger <[EMAIL PROTECTED]> writes:
NW> Also, how about just $@->id? Shorter and I would argue the "unique_" is
NW> really redundant (id's are usually unique, hence the name
NW> "identifiers").
Not really.
Consider: Chaim is an identifier. But not unique.
--
Chaim Frenkel
On 10 Aug 2000 22:26:47 -, Chaim Frenkel <[EMAIL PROTECTED]> wrote:
> =head2 Encodings
>
> I have listed some possiblities. But none of these are ideal.
>
> =head3 A unique number
> =item As an integer
> =item As a floating point number
> =head3 Unique String
> =head3 Prefixes for all error
> well, if it is only a string, why use . as the separator? use something
> else like : and no one will try any fancy math tricks on it.
Agreed. I like :, it's a common separator.
Also, how about just $@->id? Shorter and I would argue the "unique_" is
really redundant (id's are usually unique, h
At 10:42 PM 8/10/00 -0400, Chaim Frenkel wrote:
>PS> Can this be merged with RFC 80, or do they need to live apart?
>
>I believe they do. This portion can independently survive without
>an exception mechanism. I'm only addressing the "what error did
>I get". You are addressing the error handling m
I'm leaning to splitting identifier from the classification.
A pure monotonically increasing integer would ensure the non-reuse.
And the classification scheme could evolve seperately.
Using numbers for the classification scheme would require a translation
table. So why not just use alphanumeric
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
AS> 2. Error codes as digit strings with decimal point. So "123.4567"
AS>(_not_ 123.4567) represents error 4567. People will still try
AS>stupid floating-point math tricks to get at the suberror code, but
AS>at least
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes, for Chaim Frenkel
<[EMAIL PROTECTED]>:
[...]
> =item As a floating point number
>
> The integer part would be the actual identifier. The fractional
> part could encode some classification scheme.
Floating point numbers don't work this way. Supp
Chaim Frenkel wrote:
>
> [stuff about exception numbering]
>
> Hmm, I thought I saw another exception RFC pass by.
> Yup, RFC 88, Tony Olekshy <[EMAIL PROTECTED]>
>
> Could you two folks get together and hash this out.
RFC 88 goes to some trouble to seperate exception handling from
exception obje
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>> =head1 TITLE
>>
>> All perl generated errors should have a unique identifier
PS> This looks awfully similar to RFC 80. Certainly the exception objects RFC
PS> 80 is thinking about can well have unique numeric attributes.
>> All perl ge
>=head1 TITLE
>
>All perl generated errors should have a unique identifier
This looks awfully similar to RFC 80. Certainly the exception objects RFC
80 is thinking about can well have unique numeric attributes.
>All perl generated errors should have a unique identity. So that
>changes in the
On Thu, 10 Aug 2000, Perl6 RFC Librarian wrote:
> All perl generated errors should have a unique identity. So that
> changes in the text should not cause breakage in code.
>
Good idea. A lot of programs do this. It could make it easier to
handle error callbacks. (If you ever get a 'no space l
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
All perl generated errors should have a unique identifier
=head1 VERSION
Maintainer: Chaim Frenkel <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number:
85
All
13 matches
Mail list logo
