veryShortName

Greetings,

I have been looking at FileMan and had some confusion with #FmFileEntry>>shortName.

'this.that.txt' asFileEntry name. ==> 'this.that.txt'
'this.that.txt' asFileEntry shortName. ==> 'this'  

I expected #shortName to answer the same result as baseName.

'this.that.txt' asFileEntry baseName. ==> 'this.that'

I find the current behavior confusing.  Is there a real need to have #shortName differ from #baseName?

If the current #shortName behavior is required, could the name be changed to something nore mnemonic.  Perhaps #firstPrefix ?

Thanks much,
-KenD




--
KenD <[hidden email]>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi all,

Actually I sometimes uses #shortName for selecting package name part
from MCZ files (package.123.mcz).
In this case, package name part is not prefix. But #shortName is not
so clear, neither.

Perhaps #firstName or #nameUpToDot would be better?

Best regards,

2015-10-13 0:05 GMT+09:00 KenD <[hidden email]>:
--
[:masashi | ^umezawa]

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On Sat, 17 Oct 2015 14:28:23 +0900
Masashi UMEZAWA <[hidden email]> wrote:

> Perhaps #firstName or #nameUpToDot would be better?

Yes.  Either works for me.

Thanks,
KenD <[hidden email]>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On 17/10/2015 11:39 a.m., KenD wrote:
> On Sat, 17 Oct 2015 14:28:23 +0900
> Masashi UMEZAWA<[hidden email]>  wrote:
>
>> Perhaps #firstName or #nameUpToDot would be better?
> Yes.  Either works for me.
>
> Thanks,
> KenD<[hidden email]>
>

Besides #shortName, we also have #splitNameVersionExtensionFor:,
#baseNameFor:, #baseName, etc. Reducing their number would be good. As
it would be to separate those that give a "standard service" from those
that just solve a more specific need of some client code.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi all,

Indeed, we should avoid adding ad-hoc methods.

Currently I'm thinking to introduce a more generic API (splitName:by:)
to FmFileIOAccessor.
So we can implement FmFileEntry methods more consistently like:

FmFileEntry >> firstName
   ^ (self fileAccessor splitName: self name by: self extensionDelimiter) first

FmFileEntry >> extension
   ^ (self fileAccessor splitName: self name by: self extensionDelimiter) last

FmFileEntry >> baseName
    | names |
    names := self fileAccessor splitName: self name by: self extensionDelimiter.
    names size = 1 ifTrue: [^names first].
    ^self extensionDelimiter join: names allButLast

Best regards,

2015-10-24 2:22 GMT+09:00 Juan Vuletich <[hidden email]>:


--
[:masashi | ^umezawa]

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On Sun, 25 Oct 2015 23:15:18 +0900
Masashi UMEZAWA <[hidden email]> wrote:

> Currently I'm thinking to introduce a more generic API (splitName:by:)
> to FmFileIOAccessor.

That would be great!

Juan, would you let me know when this is integrated?

I/we need to update/replace StandardFileMenu.

Thanks much,
-KenD

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org