another thought:
the documentation can hide a flat namespace.
on the filesystem the flat namespace could be broken up too by
introducing several subdirectories (instead of /modules/Parser.pmod/ it
could be just /modules/parsers/) which are added to the search path for
modules.
so you get a flat n
doing the categorisation in the documentation even if it is a single
hierarchy allows making changes and move things around to improve the
structure without breaking anyones code.
greetings, martin.
What you're describing is categorization. It's not the same thing as an
hierarchy - using a hierarchy for categorization limits you to one
category only, which is often insufficient. E.g. XML is both a standard
and a format that can be parsed, and we can't put it both in Parser.pmod
and Standards.p
"Stephen R. van den Berg" wrote:
> I now have a cmod which is in a subdir src/post_modules/USB, which
> gives me an USB.devices(), USB.Iterator(), USB.device() and
> USB.transfer().
I take it that neither USB.devices nor USB.device are objects, since
they start with lowercase. What are the names
I now have a cmod which is in a subdir src/post_modules/USB, which
gives me an USB.devices(), USB.Iterator(), USB.device() and USB.transfer().
The usual way this works, is that one starts with:
object dev=USB.devices();
and then you do a foreach() which gets the Iterator, which delivers
"Stephen R. van den Berg" wrote:
> Erm, these are not svalues, but objects, so move_svalue() cannot be used.
> Any other suggestions?
No, for that there aren't any fancy macros that I'm aware of.
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
>And the most obvious way to do that is to put the module in a
>container so you don't have to look at the documentation to at least
>know what to avoid... :)
:-). Well, not quite. Without looking at the documentation, one
nor
And the most obvious way to do that is to put the module in a
container so you don't have to look at the documentation to at least
know what to avoid... :)
Martin Stjernholm wrote:
>"Stephen R. van den Berg" wrote:
>> if((THIS->foo=foo))
>> { debug_malloc_touch(THIS->foo);
>I suggest replacing this bit with the move_svalue macro:
>if (foo) {
> move_svalue (THIS->foo, foo);
>It has some debug stuff to detect if the old svalue is u
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
>Well, you will have to create the namespaces in documentation then,
>otherwise you don't know which of the top level modules you are
>looking for or which you don't have to look at.
Correct. But that is solvable, and indeed sh
Well, you will have to create the namespaces in documentation then,
otherwise you don't know which of the top level modules you are
looking for or which you don't have to look at.
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
>I think it is good with containers that tells you the context for a
>module. Some modules are misplaced, some containers are misnamed, but
>I prefer that over having ZPRLQX et.al. popping up in the top name
>space with no inform
Martin B?hr wrote:
>on the other hand, any low level stuff like Nettle, Mysql, Odbc,
>Postgres, ie. modules that contain a warning that they should not be
>used unless you know what you are doing, could probably be moved into
>Crypto and Sql respectively.
I think we agree on this in principle.
As
H. William Welliver III wrote:
>Though, also keep in mind that not everyone is going to be able to use
>libusb, so while I don't advocate over-classifying things, it might be
>somewhat ill-considered to use a generic (USB) name for something that's
>actually quite implementation specific, unless yo
>
> From: Martin Bähr
>To: Stephen R. van den Berg
>Cc: "Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum"
><10...@lyskom.lysator.liu.se>; pike-devel@lists.lysator.liu.se
>Sent: Saturday, June 9, 2012 12:01 PM
>Subject: Re: USB.devices OneWire.device
>
> From: Martin Bähr
>To: Stephen R. van den Berg
>Cc: "Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum"
><10...@lyskom.lysator.liu.se>; pike-devel@lists.lysator.liu.se
>Sent: Saturday, June 9, 2012 12:01 PM
>Subject: Re: USB.devices OneWire.device
I think it is good with containers that tells you the context for a
module. Some modules are misplaced, some containers are misnamed, but
I prefer that over having ZPRLQX et.al. popping up in the top name
space with no information on if it is a file format, a data type, an
image format etc.
As a second datapoint, I've created a few modules (not all public, though),
that I've placed in Public.IO, and my thinking pretty closely aligns with what
Stephen has indicated: modules for operating with non-software I/O devices.
Another datapoint from outside Pike: Apple's IOKit is all about d
as much as i like a nice clean hierarchy, i have to admit a flat
namespace is better than a bad hierarchy.
to the generic module containers Parser, Protocols and Standards which
could probably be moved to the top level i'd also like to add ADT,
Languages and Web
on the other hand, any low level s
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
>>Martin Stjernholm wrote:
>>>"Stephen R. van den Berg" wrote:
>>Then I thought about what these things are about, and decided that the
>>(in my mind) logical group I'm thinking about all has to do with
>>*hardware* I/O.
>Hmm... Maybe
"Stephen R. van den Berg" wrote:
> Then I thought about what these things are about, and decided that the
> (in my mind) logical group I'm thinking about all has to do with
> *hardware* I/O.
Maybe Peripherals, Interfaces, or Bus, then? Although I still believe
the distinction between that and Pr
>Martin Stjernholm wrote:
>>"Stephen R. van den Berg" wrote:
>
>>> Most logical would be under a module named IO, so it would
>>> become IO.USB.devices and IO.OneWire.devices or somesuch.
>
>>IO sounds like a container module for all things i/o, but in reality
>>there's already a whole lot of i/o
Martin Stjernholm wrote:
>"Stephen R. van den Berg" wrote:
>> Most logical would be under a module named IO, so it would
>> become IO.USB.devices and IO.OneWire.devices or somesuch.
>IO sounds like a container module for all things i/o, but in reality
>there's already a whole lot of i/o elsewher
23 matches
Mail list logo
