28966 - Remove implementation exposing methods from nsILocalFileMac

Status: VERIFIED DUPLICATE of bug 100828

(Core :: XPCOM, defect, P3)

Description

[Doug Turner (:dougt)]

These functions should not be in the interface as they discuss implementation 
details:

GetInitType
SetAppendedPath
GetAppendedPath

These entry points are confusing to say the least:

GetFSSpec
GetResolvedFSSpec
GetTargetFSSpec

Comment 1

[Steve Dagley]

For proper cloning of an nsLocalFileMac you need GetInitType, SetAppendedPath and 
GetAppendedPath and GetFSSpec.  I forget why I added GetResolved and GetTarget 
but they are potentially useful.

Comment 2

[Doug Turner (:dougt)]

steve, these do not have to be in a public interface.  The details of cloning 
should be left to the implementation.

Comment 3

[Steve Dagley]

Private interfaces for an XPCOM object?  News to me.  I'd say feel free to create 
one for the methods that offend you but you should be talking to whoever is 
responsible the Mac impl now.

Comment 4

[Simon Fraser [no longer active]]

dougt is saying that these do not need to be in nsILocalFileMac, but can remain 
in nsLocalFileMac (say, as protected methods)

Comment 5

[Doug Turner (:dougt)]

targeting m16.  If you reported this bug, and you would like to have it fixed 
sooner, please send me email.  I will see what I can do.  :-)

Comment 6

[Doug Turner (:dougt)]

scc, could you help out on this?

Comment 7

[Scott Collins]

I'm happy to help with this; but making it fairly low priority.  There are 
several simple but sweeping interface changes that I want to make (this now 
being one of them) which I'll use as filler in between hard bugs ... so the fact 
that I'm marking this M20 does not mean I won't be fixing it sooner.

Comment 8

[Scott Collins]

mass re-assigning to my new bugzilla account

Comment 9

[Scott Collins]

The suggestion from macdev was to re-assign this bug to you, conrad.  You can
decide if it's still valid.

Comment 10

[Conrad Carlen (not reading bugmail)]

I completely agree with the initial claim in this bug. I have wondered why we
needed accessors to the appended path. I also think it's questionable to use 3
specs to represent one file internally, but making it public is certainly not good.

Comment 11

[Conrad Carlen (not reading bugmail)]

Setting milestone to mozilla0.9. Hopefully, I can get to this sooner.

Comment 12

[Conrad Carlen (not reading bugmail)]

-> 0.9.1

Comment 13

[Conrad Carlen (not reading bugmail)]

Moving off again. This should probably wait until the nsIFile API is possibly
split and reworked.

Comment 14

[Conrad Carlen (not reading bugmail)]

Working on this along with some other nsILocalFileMac cleanup.

Comment 15

[Conrad Carlen (not reading bugmail)]

This is all fixed in the patch for bug 100828.

*** This bug has been marked as a duplicate of 100828 ***

Comment 16

[Simon Paquet [:sipaq]]

verified.