RFC: new alias names in BigInt
Tels
Moin,
a lot of changes in BigInt were done to make the interface consistent. This
involved f.i. that you can call all methods in BigInt or BigFloat with no
exceptions. However, lately a few inconsistencies tripped me up (e.g. even I
forget which method is which):
* is_int(), is_zero(), is_inf(), etc are all short names, with two exceptions:
is_positive() and is_negative()
I plan to add two alias names, is_pos() and is_neg() and announce these in the
doc,and is_positive() and is_negative() will be mention as "for compatibility
reasons".
* we have as_hex, as_bin but not as_dec() nor as_int(). Actually, as_dec() is
simple "$x" or bstr(), while as_int() is named as_number() (I am responsible
for this :)
I plan to add as_int() as alias to as_number(). I am not sure whether as_dec()
as alias to bstr() is really neccessary.
The aliases are quite simple and don't bloat the code much. What is your
opinion?
Comments, ideas, feedback?
Cheers,
Tels
- --
Signed on Fri Dec 19 10:46:19 2003 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"We have problems like this all of the time," Kirk said, trying to
reassure me. "Sometimes its really hard to get things burning." --
http://tinyurl.com/qmg5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBP+LKEHcLPEOTuEwVAQFdugf+OdT7gLULf5/RGHPpdg4Cg4dWwUZUwkzx
SlzqPdlq1ppIxmZygH7Lzxp4IzOWAxPfZpEEFjIR9nS5pn61AL9+DGEXEcU8gGJk
u5kDov5DCQtPYkMNrWqUOLP3cuoUWp2RZkfg/cX/PW3rv8CXg/vu6OF8Sr8iQrOp
jG8IRNBCeC5lzrQDDO5wECcUgxNVRiMWIEWCzop12WqsmRJGhusSP3IySWOHPO4g
xn6iWgi39JVvxKTSJtrQ/y1zCbz120Thyqo1lp6kaOfY0Kk8Nwqvh5l05nHgKFEU
vfLH6Q9xZlI1p1iJgJfU50JT1DYZq5IlJPBoSkU+zL0Vew+X/W9dqg==
=12ZJ
-----END PGP SIGNATURE-----
Rafael Garcia-Suarez
> a lot of changes in BigInt were done to make the interface consistent. This
> involved f.i. that you can call all methods in BigInt or BigFloat with no
> exceptions. However, lately a few inconsistencies tripped me up (e.g. even I
> forget which method is which):
> The aliases are quite simple and don't bloat the code much. What is your
> opinion?
Nice new names ; but are you going to deprecate the old ones ? For the
sake of backward compatibility, I'm afraid you'll have to support them
*forever* :) and make sure you document new aliases as "new as of
version XYZ". Math::BigInt is large enough so the addition of a couple
aliases won't be a heavy overweight. That's all I have to say : general
considerations.
Consider yourself unwarnocked :)
Tels
Moin,
On Sunday 21 December 2003 18:10, Rafael Garcia-Suarez wrote:
> Tels wrote:
> > a lot of changes in BigInt were done to make the interface consistent.
> > This involved f.i. that you can call all methods in BigInt or BigFloat
> > with no exceptions. However, lately a few inconsistencies tripped me up
> > (e.g. even I forget which method is which):
>
> ...
>
> > The aliases are quite simple and don't bloat the code much. What is your
> > opinion?
>
> Nice new names ; but are you going to deprecate the old ones ? For the
> sake of backward compatibility, I'm afraid you'll have to support them
> *forever* :)
That was the plan, yes.
> and make sure you document new aliases as "new as of
> version XYZ".
Good idea. CHANGES lists the overall changes, but not when they occured. I
think I need to track this info somehow. Or just have everyone finally
upgrade to the newest version, thank-you-very-much-I-am-here-all-week :)
> Math::BigInt is large enough so the addition of a couple
> aliases won't be a heavy overweight. That's all I have to say : general
> considerations.
>
> Consider yourself unwarnocked :)
Hm. The idea was to document the new ones and just let the old ones "live
quitly in the basement forever". However, I see you point, as soon as someone
uses the new names, their code becomes incompatible with older BigInt
versions.
However, if someone still uses an old BigInt, I would strongly consider
upgrading, just because of all the bugs, new aliases or not. I know some ppl
still use v0.01 because thats what came with their perl and it works (sorta)
and they don't want to upgrade. However, I can't please everyone :-)
If anyone is concerned about having their code run under old versions, they
can use the "older" alias name. That should please as much ppl as
possible... :)
Best wishes,
Tels
- --
Signed on Sun Dec 21 18:19:54 2003 with key 0x93B84C15.
Visit my photo gallery at http://bloodgate.com/photos/
PGP key on http://bloodgate.com/tels.asc or per email.
"Zudem könnten nun nicht mehr nur Täter, sondern auch Opfer abgehört
werden, um diese besser zu schützen." Jörg Bode, FDP -
http://heise.de/newsticker/data/anw-11.12.03-003/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.
iQEVAwUBP+XXjHcLPEOTuEwVAQGL4wf/VEX8BZmwyBx9zoyGfQsYuLRj1kFAYmq3
KM8P+AxZPVqyUNMSCw5oUCDrZfBba5TJyI6IzdZLlSkF1aSvBEO5FZuKJnXQtfdv
phXmM89nTnPJjCW14QslUxmZQ4Pfd7ESgL029jbcibDt4ULSkIjiNgJ6Bf7qQ5Mn
iAQVFKrz0jHN0PtOqNYN07mTsT+S+ziTJFurDNEcdNDR8SJvBRW+MBY2URjd98yI
18M7EHtXgZA6KWArm/qpsTnYvjzAR6NrUwIkxIjJZckH/C18Cto7g8sCKOlv8Kl6
6U8lKMotoOkgf8qj2mSIFiLj+cc7LDuHrS/SQKCXPdQ0ra3zgCvuTw==
=h2xA
-----END PGP SIGNATURE-----