Re: [Alephmodular-devel] On CfileDesc and handling navigation

[Br'fin <br...@ma...>]

And after a little further thought and research, I have to wonder. 'Why 
the heck do we need a GetParent/navigate_up anyhow?' If there's 
anything we need, then it should either already be in or under a 
specified directory.

We find the preferences directory and write preferences within it. We 
find the application's directory and find support files within or under 
it.

Unless anyone can field a good argument for why we would want it, I'm 
inclined to nix it from the available APIs.

-Jeremy Parsons

On Monday, February 10, 2003, at 08:36  AM, Br'fin wrote:

> I've been using my draft as a guide and piece by piece implementing 
> portions using or replacing bits of the existing API. (For instance, 
> the checked in code now uses iostreams and CFileTypes)
>
> And my own build has begun using a simpler version of CFileDesc as the 
> internals to the existing API.
>
> Kind of neat having opening a file be in CFile.cpp. With the platform 
> specific bit of converting the platform's internal representation to a 
> name compatible with new std:ifstream being handled by the platform 
> subclass. :)
>
> I am, however, having distinct second thoughts about creating a new 
> CFileDesc for each navigation. Seeing how memory management of the 
> various C++ classes is annoying, the prospect of editing a CFileDesc 
> in place is appealing to me more and more.
>
> instead of
> 	GetParent			- new CFileDesc
> 	GetNamedChild		- new CFileDesc
>
> more of
> 	clone()			- new CFileDesc
> 	navigate_up()		- modifies current CFileDesc
> 	navigate(child)	- modifies current CFileDesc
>
> -Jeremy Parsons
>