Folderitems are over complex.
I would never call FolderItem "over complex". It's pretty straight forward and easy to understand.
Why have binarystream and text streams? They are the same thing.
I suppose the value of text streams could be debated, but it's hard to argue that FolderItem is too complex for offering a *simplified* stream set for the most common file I/O task.
Relative paths are the simpler more modern way that works everywhere. But RB has no concept of a current directory or a relative path, at least not a proper one. I wish RB would just do file paths the Unix way, but their getfolderitem doesn't allow for relative paths!!! Ridiculous.
RS should add a FolderItem.GetFolderItem(RelativePath) to the class. But I don't consider the lack of such a function proof that FolderItem is complex. And it's easy to add yourself.
In Cocoa, I can do something like this: dim s as string s = "file data" s.WriteTo "/path/to/file.txt"
No you can't. You have to first lookup the NSString method for producing NSString objects from the "C string" constants you type. Then look up the encoding you need to use. Then write the two lines of code to coerce your strings. Then you can call WriteTo with your new NSStrings, but you should also pass a variable pointer for the error which may be returned and examine it, another couple lines at least.
NSString.WriteTo is convenient as a one line open-save-close, but dealing with strings in Cocoa is typically more of a headache than in BASIC. (That's true of any of the C derived languages vs. the BASIC derived languages.)
And NSString.WriteTo is not representative of the entire Cocoa framework. It's just a short cut method off NSString. I'm sure if I felt like it I could find a similar example where something in Cocoa takes a few lines but one in RB. Such examples don't give an overall picture. I've written a small application for a client in both RB and Cocoa. It had to be ported to Cocoa because the client wanted Intel support right away and they were willing to pay for it. Other than Intel support, it was identical in features and UI and they had no issues with the RB version. The Cocoa version was more complex code wise and took more time. The difference wasn't dramatic, but I certainly noticed it.
That's it. You wanna tell me that RB's way with binarystreams, folderitems, enforced using of .child and all the rest of it, is simpler?
You're holding up a shortcut method which just happens to be part of NSString, without some of the necessary lines, against RB's file framework. That's apples and oranges.
RB's editfield really is superlacking, also. Styling is a pain, and slow.
True of every framework and OS text editing widget. That's why products like Word have their own. None of the OS widgets are designed to be pushed hard. If you want to challenge Excel, you better roll your own list box. If you want to challenge Word, you better roll your own edit field. That's life.
Don't get me wrong, I'm all for improvements. But I don't expect any OS or framework widget to be suitable beyond a certain point.
RB's listbox is done the wrong way also. It should be using some kind of datasource, like Apple do it. In fact it should be done entirely like Apple do it ;) maybe a bit simpler here and there but the same structuring, because Apple's approach really works.
Requiring a datasource is not always simple. When you just want to throw something up on the screen, and that "something" is not pre-packaged as an appropriate provider, having to get it packaged is a pain. (I'm speaking generically because this is true across environments.)
I would be fine with a subclass of ListBox that connected to a datasource and a generic interface for us to use in implementing sources, but I would not want to see ListBox require it.
Daniel L. Taylor Taylor Design Computer Consulting & Software Development [EMAIL PROTECTED] www.taylor-design.com _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
