Finder and «class furl»

Am I missing something.
Using some ASObjC pieces of code, I may get POSIX path or file objects which are in fact «class furl» ones.

Sometimes, I must use “Finder” to make some treatments and I get puzzling behaviors which you will see as comments in the sample below.

set unHfs to choose folder
set unPosix to POSIX path of unHfs
set aFile to POSIX file unPosix
log class of aFile
tell application "Finder"
	try
		exists aFile
		log result --> true
	on error errMsg number errNbr
		log "Error #" & errNbr & ", " & errMsg
	end try
	try
		name of aFile
		log result
	on error errMsg number errNbr
		log "Error #" & errNbr & ", " & errMsg
		(*Error #-1728, Erreur dans Finder : Il est impossible d'obtenir name of file "SSD 500:Users:yvankoenig:Desktop:2002 après:".*)
	end try
	try
		set locked of aFile to true
		log result
	on error errMsg number errNbr
		log "Error #" & errNbr & ", " & errMsg
		(*Error #-10006, Erreur dans Finder : Il est impossible de régler locked of file "SSD 500:Users:yvankoenig:Desktop:2002 après:" à true.*)
	end try
	try
		set label index of aFile to 2
		log result
	on error errMsg number errNbr
		log "Error #" & errNbr & ", " & errMsg
		(*Error #-10006, Erreur dans Finder : Il est impossible de régler label index of file "SSD 500:Users:yvankoenig:Desktop:2002 après:" à 2.*)
	end try
end tell

I’m surprised to see that the Finder is able to see that a «class furl» object is available but seems to be unable to get or set properties of the same object.
Am I missing something ?
I thought to a conflict between file as class defined by the Finder and file as prefix of a «class furl» object but if it’s that it would logically strike with exists command too.

Yvan KOENIG running El Capitan 10.11.6 in French (VALLAURIS, France) jeudi 15 septembre 2016 11:52:35

The difference in here is command/class vs. object specifiers. The command exists is a straightforward command doesn’t need any resolving of the object specifier but will do when needed. The other instructions are object specifiers and not commands. The object then send is not an object but a specifier (value, want, is, self) and needs to be resolved. For the command the object can easily be coerced as long as AE supports it or an special coercion handler is installed. However resolving is something else, it requires that you define the from and to type resolve handlers.

Simply Put: The Finder doesn’t support furl classes but AE does. This means commands using implicit coercion handlers will work fine with furl classes because it will use the system’s default coercion handlers, while object specifiers has no default or system resolve handlers and has no support for it by default.

Thanks

I was not dreaming about the different behavior.
I will try to remember why it strikes.

Yvan KOENIG running El Capitan 10.11.6 in French (VALLAURIS, France) jeudi 15 septembre 2016 15:44:09

Hey Yvan,

That’s why I always use HFS paths and aliases when working with the Finder “ so I don’t have to remember the problematic cases, and my code just works.

-Chris