[Cuis-dev] fix for leading tilda in DirectoryEntry, or am I going about this the wrong way?

[Imran Rafique]

Got it. For base image changesets, think long and hard before introducing a
new type of object, no matter how trivial.

Thanks.

On Fri, Jul 28, 2023, 6:33 AM Juan Vuletich <juan at cuis.st> wrote:

> Hi Imran,
>
> On 7/27/2023 7:50 PM, Imran Rafique via Cuis-dev wrote:
>
> Juan,
>
> Thanks for taking the time to point me in the right direction. Much
> appreciated. Yes, lots I hadn't thought of.
>
> Just one question: in Cuis, do you prefer to not have specific Error
> subclasses and just call 'self error:' ?
>
>
> It is a more general idea. Anything that goes in the image has an upside
> and a downside. A benefit and a cost. The upside includes the
> functionality, the insights it may teach readers, expandability, etc. The
> downside is _not_ the time it takes to write code. That is only paid once.
> It is not the memory required. In most cases there is so much memory that
> even a couple of kb mean nothing. The real cost is the cognitive burden on
> readers. Another thing to understand and remember about. In Cuis we work
> hard to keep complexity low. That means, for example, avoiding new classes
> that don't carry their own weight. Classes are globals. They take room in
> the global namespace, and they show up often, no matter what you are trying
> to focus on. In general, classes in the base image are irrelevant to the
> problem you are working on. The less of them, the better. The more relevant
> they are, the better.
>
> In this case, handling tilde is worth a few lines of code. But not a new
> class unless it is really needed, and even then maybe the decision would be
> not to handle tilde at all! It is not _that_ important, and any app can
> require OSProcess and handle it itself. But a couple of lines of code is
> ok, so they are in.
>
> Other exceptions are used more often, and many programmers will prefer to
> know about them and perhaps handle them. Those are included in the base
> image.
>
> WRT to library or application code, it is up to you, or the developers of
> the library or app. In that context they will judge what is relevant, and
> what knowledge they want to embody in the software.
>
> Hope this makes sense to you.
>
> Cheers,
>
>
> On Thu, Jul 27, 2023, 1:27 PM Juan Vuletich <juan at cuis.st> wrote:
>
>> Hi Imran,
>>
>> There are a few issues with your change set.
>> - It breaks paths like '../../stuff' .The loop was there for a reason.
>> - Even with OSProcess it is possible that the $HOME variable is not
>> defined.
>> - Holding a workaround folder in a class variable can be problematic,
>> especially if the image is saved. Or if OSProcess is loaded after this.
>> It can also hide this problem for other code that asks for a folder.
>>
>> I pushed instead a different implementation that addresses this issues,
>> as update #5898.
>>
>> To handle the situation you can do something like
>>
>> [ '~/Toto' asDirectoryEntry ] on: Error do: [ :error | error description
>> print. error retryUsing: '/elToto' asDirectoryEntry ]
>>
>> Having the description of the error in available in a method lets you
>> validate the kind of error, to be sure.
>>
>> Finally, to test base image functionality, a change set to be loaded in
>> BaseImageTests is OK. If you also want to test the behavior with
>> OSProcess loaded, another test for the OSProcess package is an
>> alternative. In that test, don't forget to test that the HOME variable
>> can be resolved, and do nothing if not. Otherwise the test will fail in
>> some environments (I can think of Windows, but I'm sure there are others
>> where HOME is not an environment variable).
>>
>> Thanks,
>>
>> On 7/27/2023 11:07 AM, Imran Rafique via Cuis-dev wrote:
>> > Juan&  Hernan,
>> >
>> > I **think** the attached changeset does what you wanted. I may have
>> > overcomplicated things somewhat, but in any case, its a great learning
>> > experience.
>> >
>> >
>> > Gives an exception if OSProcess is not available:
>> >
>> >      '~/foo' asFileEntry.
>> >
>> >
>> > Sets a default homedir in case we cannot read environment variables:
>> >
>> >      [ '~/foo' asDirectoryEntry ] on: NeedsPackage do: [ :ex |
>> > FileIOAccessor homeDirDefault: '/home/guess'. ex retry ]
>> >
>> >
>> > BTW, whats the preferred way of including tests for changesets like
>> this?
>> >
>> > --
>> > Regards,
>> >         Imran Sher Rafique
>>
>> --
>> Juan Vuletich
>> cuis.st
>> github.com/jvuletich
>> researchgate.net/profile/Juan-Vuletich
>> independent.academia.edu/JuanVuletich
>> patents.justia.com/inventor/juan-manuel-vuletich
>> linkedin.com/in/juan-vuletich-75611b3
>> twitter.com/JuanVuletich
>>
>>
>
> --
> Juan Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20230728/4190be0c/attachment-0001.htm>