Quoting [Ceriel Jacobs] (Aug 17 2009):
If the above works, I don't see why
saga::file::entry e (u);
should not work. Or am I missing something? The same then also holds for the open methods - the origin of Matijs' complain.
It is a major semantics change. If you do that, all methods in the ns_entry implementations now have to consider the possibility that the entry in fact is a directory, whereas earlier they could just be hidden by ns_directory implementations.
But yes, that is how it is supposed to work, IMHO. For example, the spec states what happens on entry.copy() if the entry happens to be a directory. And similar for other calls on entry.
Also, I think it is confusing that you can have a ns_entry object that represents a directory but cannot be casted to a ns_directory. Note that I don't have an issue with the change in the ns_directory.open method, only with the change in the ns_entry constructor which, being a constructor, cannot deliver a ns_directory.
No, it does not deliver an ns_directory. The following would *not* work: saga::url u ("file://localhost/etc/"); saga::file::dir * f = new saga::file::entry (u); That would be technically impossible I think. But (again) the following should work: saga::url u ("file://localhost/etc/"); saga::file::entry * e = new saga::file::entry (u); I still don't see a reason why that should be invalid. Matijs' use case seems very valid to me: saga::url u ("file://localhost/etc/"); saga::file::entry * e = new saga::file::entry (u); if ( e->is_dir () ) { saga::file::dir * f = new saga::file::directory (u); } Cheers, Andre. -- Nothing is ever easy.