Re: [pclasses-devel] P::Classes experimental code

[stephan b. <st...@s1...>]

On Wednesday 22 December 2004 20:05, Christian Prochnow wrote:
> Place URL in Net/.  

Will do.

> SQL stuff isn't ported yet and needs major 
> rework. However .. i think the String class must be done before
> starting with the URL class. 

Will the string support implicit conversion from (char *) or 
std::string? If not, i would prefer to see URL based off of 
std::string. If there's an implicit conversion, i see no problem with 
basing URL off of it.

> What about support for 
> internationalization in the URL class (don't remember the correct
> name)?

i know very little about i18n, so i can't say much about it.


> > - Add Request::read( string &, size_t ). Doh - Request isn't ported
> > to pclasses2 yet.
>
> We first need a Plugin library. Since Plugin loading is not a core
> component, and isn't a System abstraction class either it should go
> into it's own P library. Stephan .. how about your excellent
> class_loder stuff ? Shall i integrate it into P and drop the old
> Plugin stuff ? your code is much more elegant and cleaner.

*blush*. Actually, earlier today i was thinking about how horrible one 
of the classloader's "features" is, and want to rewrite it. i like the 
cllite interface a lot, though, and i get TONS of usage out of it. That 
said, i will be more than happy to add a classloading layer to P. i'd 
be honored, in fact, to be allowed to port my code into the tree :).

> > - Port some utility functions out of ps11n into P, like
> > iomanager_read(string url), which reads in input from any
> > IOManager-supported type.
>
> Should go into P::IO library.

Agreed. i will generally follow the policy of "put it wherever it'd deps 
say it should." If new dependencies would be introduced i will first 
ask for your approval.

> > - Maybe port the build tree to toc (the tools s11n uses). This
> > depends on Christian's decision.
> >
> > - Add a new shell-app module:
> >   - add argv handling.
> >   - add command dispatcher
> >   - add eshell's argv type ('arguments').
>
> Hmm .. should this go into Util/ or shall we add a "application
> support" library ?

i think argv belongs in the Util section, and the rest as a standalone 
module or plugin, but i'm not sure what the plugin abstraction might 
look like yet.

> For example SimpleApp should go into "application support" lib, i
> think argv handling as well.

That'd work, too. That makes more sense, actually.

> If argv handling is "generic" and doesn't rely on input from
> "main(int, char*[])" it should go into Util/.

The argv PARSER does not strictly rely on main(), but is not much use 
without it. The argv TYPE is 100% independent. The argv TYPE is simpy a 
sequence container of args with some features to ease it's use as an 
argc/argv replacements. The features like $var/alias expansion depend 
on the app layer (Environment and Aliases objects), so the argv list 
probably belongs there as well.

That's a long way of saying: the ArgvParser class belongs in util, the 
Arguments (Argv?) class belongs in the app utils.

> Seems that this Christmas becomes a funny hacking session ...

That's how i usually spend them. :)


-- 
----- st...@s1...   http://s11n.net
"...pleasure is a grace and is not obedient to the commands
of the will." -- Alan W. Watts