RG <rNOSPA...@flownet.com> writes:Actually, this is too verbose. It also has the problem that you can do
> In article <m2lj2ky56e....@host-10-5-17-33.vaih.selfnet.de>,
> Edmunds Cers <edmu...@laivas.lv> wrote:
>> RG <rNOSPA...@flownet.com> writes:
>> >> What problem does "org.tfeb.xml.parser" offer?
>> > Verbosity.
>> You are free to add a nickname of your liking:
> If you're willing to do that then you don't need uniqueness at all.
> That's even simpler.
that only in the ultimate integration. If you publish your code, you
cannot be sure that nobody won't want to integrate it with another body
of code that already use those nicknames.
There should be no nickname pre-defined on published packages.
Long package names are not a problem in practice, because either you
If you observe the opposite, then you have another problem: your cross
>> > Also, it doesn't even guarantee uniqueness because domains can changeThis is nto a problem either, because:
>> > ownership.
1- this doesn't occur often,
2- you can easily distribute a different library with other package
Point 2 is even what you should do if you plan to distribute discrete
>> It also doesn't exclude malice. Guess we have to choose between strong(21EC2020-3AEA-1069-A2DD-08002B30309D:WITH-GENSYMS
>> cryptography and nothing, right?
> That's a little extreme. GUIDs are probably sufficient.
(wall door window roof) ...)
Granted, GUIDs may be shorter, but I still prefer the reversed domain
> But what one really ought to do IMHO is to pop up a level and askIt won't be bad to think about it, but IMO packages solve 90% of the
> whether a mechanism intended to provide read-print consistency for
> symbols is really the right tool for the job of modularizing code.
modularization needs, and if you want to solve the modularization
problem, in the scope of Internet and open software, you will find that
you have to solve this same problem.
There's already the notion of relative packages (which requires reader
We could introduce modules, and optionally qualify packages with a
It's simplier to use relative package names, when the facility is/will
is future-compatible with them.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.