Smalltalk › Instantiations

System primitiveIniFileFullPathAndName

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Wayne Johnston

System primitiveIniFileFullPathAndName

It sure is tempting to use

System primitiveIniFileFullPathAndName

to tell me the ini file being used by an image. Unfortunately it's private. Anyone mind if I use it? ;-)

I'm on Windows. Using that method seems easier than "parse the command line for -ini: and if it's not there it must be named after the image file specified by -i and if the image file isn't specified it must be named after the exe".

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/d/optout.

Louis LaBrunda

Re: System primitiveIniFileFullPathAndName

Hi Wayne,

As you may know, in Smalltalk a designation of private is more of a warning against use than a prohibition of use. If you use private methods and for some reason something about how they work changes, Instantiations could (not that they would) say too bad it was a private method. So go ahead.

But when I try it on both v8.0.3 and v8.6, only the file name is answered without the path. Odd given the method name.

Lou

On Thursday, May 22, 2014 5:42:06 AM UTC-4, Wayne Johnston wrote:

It sure is tempting to use
System primitiveIniFileFullPathAndName
to tell me the ini file being used by an image. Unfortunately it's private. Anyone mind if I use it? ;-)

I'm on Windows. Using that method seems easier than "parse the command line for -ini: and if it's not there it must be named after the image file specified by -i and if the image file isn't specified it must be named after the exe".

Seth Berman

Re: System primitiveIniFileFullPathAndName

Hi all,

I would go a little further and say I would strongly discourage the use of private methods. As Lou stated, it doesn't mean "can't" in the literal sense, but methods marked in this way are subject to change or disappear without notification.

I tend to be pretty intentional about public/private markings. From release to release, I can, and often do, feel inclined to change private methods as I need to.

On the other hand, when I mark something as public, I make a commitment to that method and it's semantics. I've had many situations where I would have liked to remove or change a method, but I had marked it public...therefore I find another solution. Sometimes this means deprecating it, but still providing correct behavior.

We of course will always help our customers in any way possible, but as an extreme example, if one is writing whole subsystems off of VAST private behavior...it is not going to end well.

In this case...well...it's up to you. I would just manage this situations carefully.

-- Seth

On Thursday, May 22, 2014 9:35:20 AM UTC-4, Louis LaBrunda wrote:

Hi Wayne,
As you may know, in Smalltalk a designation of private is more of a warning against use than a prohibition of use. If you use private methods and for some reason something about how they work changes, Instantiations could (not that they would) say too bad it was a private method. So go ahead.
But when I try it on both v8.0.3 and v8.6, only the file name is answered without the path. Odd given the method name.
Lou

On Thursday, May 22, 2014 5:42:06 AM UTC-4, Wayne Johnston wrote:
It sure is tempting to use
System primitiveIniFileFullPathAndName
to tell me the ini file being used by an image. Unfortunately it's private. Anyone mind if I use it? ;-)

I'm on Windows. Using that method seems easier than "parse the command line for -ini: and if it's not there it must be named after the image file specified by -i and if the image file isn't specified it must be named after the exe".