"Leandro Lucarella" <llucax@gmail.com> wrote in message news:20080609011323.GA31950@homero.springfield.home...

> You mean *relational* database, right? Because hierarchical filesystems *are* databases (hierarchical databases in fact =). LDAP is another popular example of hierarchical database.

/me is no database expert.

Reply to Tomasz,

> Jarrett Billingsley Wrote:
> 
>> I think it might have to do with making it possible to make D work on
>> filesystems where there is no concept of "directories", such as a
>> database-oriented FS.  In such a filesystem, there might not be any
>> way to identify a module other than by doing so inside the module.
>> `select contains(*, "module foo.bar;") from files where extension =
>> "d"`.  Though even that wouldn't necessarily work since you'd really
>> have to parse the module since it could be written "module
>> foo .     bar ;".
>> 
> Interesting and sensible this db-oriented filesystem seems to be. Sort
> of an extension of the emerging tendency of getting rid of hierarchies
> and managing everything as a bag of objects with attributes. I assume
> this approach will sooner or later be hyped and the-next-big-thinged
> but heck... I'm tired of directories because of the maintainance cost
> and the where-to-put-this-file delays.
> 
> Do you know of any working solution of this kind? I googled and the
> only thing I came across was a Slashdot art saying MS strives to put
> it in the new Windows.
> 
> Tomek
> 

with a good search system like that thing in vista, google desktop or an app a friend of mine wrote*, you don't really need directories much even now.

*http://www.espsw.com/

BCS wrote:
> with a good search system like that thing in vista, google desktop or an app a friend of mine wrote*, you don't really need directories much even now.

This man would agree:
http://forums.thedailywtf.com/forums/t/7593.aspx

He's even found new uses for it:
"Video is by far the most exciting part of Search. I can video
in a book and go directly to a given page and play that back
in slow motion. I can video in forum screens."

Yigal Chripun wrote:

> Lars Ivar Igesund wrote:
>> Tomasz Sowif1ski wrote:
>> 
>>> Robert Fraser Wrote:
>>>
>>>> The "module" keyword is used to assign a name to your module (which incidentally must coincide with its filename & folder structure) while "import" gives you access to the module with the given name.
>>> By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now.
>>>
>>> Tomek
>> 
>> It is only really omittable if you have no hierarchy. The full module name is used in the symbol name mangling (for instance when compiling an object from a module using the -c switch). When you import the same module using the module name (say foo.bar.Util), your application will only link if the mangling (and module names match). The compiler can't guess the hierarchy specified by the importing code when that code isn't part of the compile. For all-at-once compiling, the compiler probably could get it right.
>> 
>> Lars Ivar Igesund
>> blog at http://larsivi.net
>> DSource, #d.tango & #D: larsivi
>> Dancing the Tango
> 
> Personally I think that the current module/package model is broken. the
> artificial distinction between modules and packages is wrong.
> if I have a bunch of small classes, should I put them in one module/file
> or have a different file for each class and group them together in a
> package/folder? and more importantly, what if I choose to change between
> having one huge file and having many small ones without changing the
> logical hierarchy of my code?
> it makes sense to put a big class in it's own file but then it's name
> would be Name.Name (since the best name of the module is the same as the
> contained class).
> what if I want to separate the logical structure from the physical one
> on disk (for a practical example - each sub project is handled by a
> different team and has it's own sub-folder but this structure is
> different from the structure of the API - Derelict's package structure
> is a good example of such issues).
> I usually do not like anything Microsoft does, but I have to admit that
> their .net separation of physical assemblies on disk from logical
> structure of the code in namespaces is genius. this is also tied with
> the C++ model of compilation which D borrows. in C# there are no header
> files at all, not even auto generated ones like D's .di files.
> 
> the latest DMD knows how to split obj files when creating a static lib. thus the 1-1 relation between code units and the compiled binary units is already broken. I think this should be taken to the next logical level and the code organization should be separated from the organization on disk. either the algorithm the compiler uses to find symbols needs to change or  another flag can be added to the makefile/dsss.conf that directs the compiler to the physical location of symbols it needs (since we all use build tools anyway to compile code) this is similar to a "project" file in a IDE.

This has been discussed before, and I agree that the current situation isn't ideal for refactoring the codebase, and there is also the estetic issue you mention (Name.Name). Dropping the current restrictions would incur more prolems with ambigiuty when resolving the hierarchy. And note that your example about the new DMD feature regarding object files really doesn't compare - they're more akin to split the source for a modules interface into several implementation files, and thus not in conflict with the current module naming scheme.

Oh, and there is a difference between "broken" and "not perfect". The current scheme does work, so it can hardly be considered broken.

Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Lars Ivar Igesund wrote:
> Yigal Chripun wrote:
> 
>> Lars Ivar Igesund wrote:
>>> Tomasz Sowif1ski wrote:
>>>
>>>> Robert Fraser Wrote:
>>>>
>>>>> The "module" keyword is used to assign a name to your module (which incidentally must coincide with its filename & folder structure) while "import" gives you access to the module with the given name.
>>>> By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now.
>>>>
>>>> Tomek
>>> It is only really omittable if you have no hierarchy. The full module name is used in the symbol name mangling (for instance when compiling an object from a module using the -c switch). When you import the same module using the module name (say foo.bar.Util), your application will only link if the mangling (and module names match). The compiler can't guess the hierarchy specified by the importing code when that code isn't part of the compile. For all-at-once compiling, the compiler probably could get it right.
>>>
>>> Lars Ivar Igesund
>>> blog at http://larsivi.net
>>> DSource, #d.tango & #D: larsivi
>>> Dancing the Tango
>> Personally I think that the current module/package model is broken. the
>> artificial distinction between modules and packages is wrong.
>> if I have a bunch of small classes, should I put them in one module/file
>> or have a different file for each class and group them together in a
>> package/folder? and more importantly, what if I choose to change between
>> having one huge file and having many small ones without changing the
>> logical hierarchy of my code?
>> it makes sense to put a big class in it's own file but then it's name
>> would be Name.Name (since the best name of the module is the same as the
>> contained class).
>> what if I want to separate the logical structure from the physical one
>> on disk (for a practical example - each sub project is handled by a
>> different team and has it's own sub-folder but this structure is
>> different from the structure of the API - Derelict's package structure
>> is a good example of such issues).
>> I usually do not like anything Microsoft does, but I have to admit that
>> their .net separation of physical assemblies on disk from logical
>> structure of the code in namespaces is genius. this is also tied with
>> the C++ model of compilation which D borrows. in C# there are no header
>> files at all, not even auto generated ones like D's .di files.
>>
>> the latest DMD knows how to split obj files when creating a static lib. thus the 1-1 relation between code units and the compiled binary units is already broken. I think this should be taken to the next logical level and the code organization should be separated from the organization on disk. either the algorithm the compiler uses to find symbols needs to change or  another flag can be added to the makefile/dsss.conf that directs the compiler to the physical location of symbols it needs (since we all use build tools anyway to compile code) this is similar to a "project" file in a IDE.
> 
> This has been discussed before, and I agree that the current situation isn't ideal for refactoring the codebase, and there is also the estetic issue you mention (Name.Name). Dropping the current restrictions would incur more prolems with ambigiuty when resolving the hierarchy. And note that your example about the new DMD feature regarding object files really doesn't compare - they're more akin to split the source for a modules interface into several implementation files, and thus not in conflict with the current module naming scheme.
> 
> Oh, and there is a difference between "broken" and "not perfect". The current scheme does work, so it can hardly be considered broken.
> 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango

I don't see any /new/ problems of ambiguity with such a scheme. The compiler will just use two completely separate mechanisms - one for resolving physical locations (i.e. files/directories) and another for resolving the logical hierarchy of symbols.

maybe my saying that the current system is broken was too strong, but it
definitely is not perfect and has issues. as the saying goes:
"good enough is the enemy of perfect"
I prefer to side with perfect while others may choose otherwise. I
wonder what is Walter's position in this regard.

--Yigal

Yigal Chripun wrote:

> Lars Ivar Igesund wrote:
> 
> I don't see any /new/ problems of ambiguity with such a scheme. The compiler will just use two completely separate mechanisms - one for resolving physical locations (i.e. files/directories) and another for resolving the logical hierarchy of symbols.
> 
> maybe my saying that the current system is broken was too strong, but it
> definitely is not perfect and has issues. as the saying goes:
> "good enough is the enemy of perfect"
> I prefer to side with perfect while others may choose otherwise. I
> wonder what is Walter's position in this regard.

Personally I think implementing such a scheme would be introducing complexity for a questionable gain - you'd rather use a tool for a major refactoring job in any case, and not depend on language mechanics.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Reply to Robert,

> BCS wrote:
> 
>> with a good search system like that thing in vista, google desktop or
>> an app a friend of mine wrote*, you don't really need directories
>> much even now.
>> 
> This man would agree:
> http://forums.thedailywtf.com/forums/t/7593.aspx

I still use directories (and don't see that changing) but more often than not the lookup/access is done through a search system.

I don't /need/ dirs the same way I don't /need/ anything higher level than ASM. :-)

Jarrett Billingsley, el  8 de junio a las 21:55 me escribiste:
> "Leandro Lucarella" <llucax@gmail.com> wrote in message news:20080609011323.GA31950@homero.springfield.home...
> 
> > You mean *relational* database, right? Because hierarchical filesystems *are* databases (hierarchical databases in fact =). LDAP is another popular example of hierarchical database.
> 
> /me is no database expert.

http://en.wikipedia.org/wiki/Database#Database_models

BTW, I'm not a database expert either, but I find very curious that people don't realize that filesystems are databases when they are probably the older most used database (and for a *lot* of problems, probably the clearer and more efficient =).

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
41% of all people take people with curly hair less seriously

Tomasz Sowiñski wrote:
> Robert Fraser Wrote:
> 
>> The "module" keyword is used to assign a name to your module (which incidentally must coincide with its filename & folder structure) while "import" gives you access to the module with the given name.
> 
> By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now.
> 
> Tomek

First, the module identifier *must* not coincide with the file path.

One case where this is useful, and not mentioned in the other replies (I think), is when a module can have multiple implementations. The module that imports find could be a .di file, for example foobar.di, while the actual implementation .d files could have other file names, for example foobar_win32.d, foobar_linux.d etc, here the module identifier is necessary to mangle symbols correctly.

If you're using Makefiles or simple scripts to build your software this is an entirely feasible setup!

Of course D has the 'version' keyword for this, but sometimes the code can be very big and seperate files might be more maintainable. I personally prefer switching my editor to another file than scrolling a hundreds of lines to look at the other implementation.

Tomas

On Tue, 10 Jun 2008 14:17:10 +0400, Tomas Lindquist Olsen <tomas@famolsen.dk> wrote:

> Tomasz Sowiñski wrote:
>> Robert Fraser Wrote:
>>
>>> The "module" keyword is used to assign a name to your module (which incidentally must coincide with its filename & folder structure) while "import" gives you access to the module with the given name.
>>  By the way, why do you have to repeat the filename in the file itself? I'm sure there must be some reason, but I can't see it now.
>>  Tomek
>
> First, the module identifier *must* not coincide with the file path.
>
> One case where this is useful, and not mentioned in the other replies (I think), is when a module can have multiple implementations. The module that imports find could be a .di file, for example foobar.di, while the actual implementation .d files could have other file names, for example foobar_win32.d, foobar_linux.d etc, here the module identifier is necessary to mangle symbols correctly.
>
> If you're using Makefiles or simple scripts to build your software this is an entirely feasible setup!
>
> Of course D has the 'version' keyword for this, but sometimes the code can be very big and seperate files might be more maintainable. I personally prefer switching my editor to another file than scrolling a hundreds of lines to look at the other implementation.
>
> Tomas


Good point!