I have been reading apple documentation and I couldn't find an answer for this questions.
In the new variables we create in Swift should we be using some of the old NSClasses (like NSDictionary) or should we use the new Swift classes (like Dictionary).
I am trying to keep consistent in use Swift classes everywhere I can but is there any difference in between the two (in this case NSDictionary and Dictionary)
Did anyone find something about this topic in the apple documentation?
This is not a duplicate of "What is difference between NSDictionary vs Dictionary in Swift?"
I know the differences and I know that one has the root class NSObject and another has the root class AnyObject. Reformulating my question I want to know how that affect me as a developer? Did anyone did a benchmark? Is it fast slower? Is apple planning to make the NSClasses obsolete in the future? And I am not limiting this discussion to NSDictionary but to the whole new variables in swift that substitute the variables pre existents in Object-C
Swift classes provide type safety which means you assume less while working with objects inside collections. So it always better to use Swift variants than Objective-C wherever possible.
Related
I'm looking for a STEP file parser for ruby that will spit out OBJ files or a model structure similar to OBJ files.
I also have found a make your own parser gem here but not quite sure how to properly set up the parser / lexer rules to use it.
I don't know if this is of any help, but I stumbled across the same problem a year ago. I had to get an IFC parser for C#. Although there are several solutions already, I decided so create my own. Therefore, I had to do the following:
Write a program (Generator), which reads an EXPRESS Schema (this EXPRESS file contains all the entities of the current IFC release defining their properties and the inheritance hierarchy) and creates all these entities as C# classes
This Generator further has to fit every so created class with the ability to write its objects to a STEP string
Put all the finished entities in a class library and use it in your main code
I also included an additional class in this class library, which can read IFC-files and then creates all the respective objects (this was really hard to do and I was not 100% successful, so it only works for certain classes for me. However, that was enough for my purpose)
So I reckon you could follow the same path just doing everything in Ruby. I hope this helped a little. Don't hesitate to ask, if you got any more questions.
I use late binding SDAI since I believe early binding (generation of C++/C# classes corresponding to STEP Entities) is not true way. I deal with AP242, AP209, AP238 (some problems were encountered, but I hope to resolve these problem), IFC. So, late binding is better way.
In swift, a lot of cocoa and framework constants have been put into namespaces. For example, NSCompositeSourceOver is now NSCompositingOperation.CompositeSourceOver.
This is generally a good thing. However, sometimes it's hard to work out where Apple have put certain constants. For example, I currently need kCGDesktopWindowLevel, and I can't find the damn thing. (There is kCGDesktopWindowLevelKey, but that's not the same thing.)
Is there a reference for this, or some set of files I can grep?
In the original CGWindowLevel.h, kCGDesktopWindowLevel is a macro defined to CGWindowLevelForKey(kCGDesktopWindowLevelKey). The macro was not imported, but the latter works fine in Swift as long as you add some type conversions: Int(CGWindowLevelForKey(CGWindowLevelKey(kCGDesktopWindowLevelKey))). (You might wish to file a bug since these type conversions are required.) You can see some of these things by ⌘-clicking on the CGWindowLevelForKey function, or using :print_module CoreGraphics from swift -integrated-repl.
I am tidying up my ancient Cocoa code to use modern naming conventions. There has been lots of discussion on best practices, but I'm unsure of one thing.
I'm thinking about adding a prefix to category method names, to ensure uniqueness. It seem generally agreed that this is a good idea, though most people probably don't bother.
My question is: what about a NSDictionary category method like -copyDeep that does a deep copy? The method used to be named -deepCopy, but I reversed the words as the analyzer looks for a prefix of "copy". Therefore I presumably couldn't add a prefix. And having the "prefix" in the middle or end of the method name seems messy and inconsistent.
I'd also be interested in thoughts on the style of prefix -- I currently use DS (for Dejal Systems) for class prefixes. But I know that Apple now wants to reserve all two-character prefixes for themselves, so am thinking about using Dejal, e.g. my class DSManagedObject would be renamed as DejalManagedObject. And getting back to categories, their methods would be renamed to add a dejal prefix, e.g. from -substringFromString: to -dejalSubstringFromString:. But -dejalCopyDeep would confuse the analyzer, so maybe I'd have to be inconsistent for such methods, and use -copyDeepDejal or -copyDeep_dejal?
I will be re-releasing my categories and various classes as open source once I've cleaned them up, so following the latest conventions will be beneficial.
I emailed the Apple Application Frameworks Evangelist about this, and got a reply that recommended not prefixing category method names. Which conflicts with the advice in the aforelinked WWDC10 session, but I assume reflects Apple's current thinking.
He recommended just looking at the beta seed API diffs to spot conflicts, which is what I've always been doing.
I agree with Kevin Ballard, you should prefix your category method names, particularly if you are going to distribute them to others. But you do have a valid concern the analyzer will be confused by DScopy. The ARC compiler will similarly be confused if the definition/implementation of DScopy is done without ARC and is used by another class using ARC (or vice versa).
My preferred solution is to use "ownership transfer annotations", such as:
NS_RETURNS_NOT_RETAINED
NS_RETURNS_RETAINED
They would be used to override the compilers default behavior of reading method names and acting on them. You might declare DScopy like so: (This declaration must be in a header file that is imported by all the classes that use this method mentioned due to link)
-(DSManagedObject *)DScopy; NS_RETURNS_RETAINED;
Source for NS_RETURNS... WWDC 2011 Session 322 - Objective-C Advancements in Depth. The meat of this issue begins at about time 9:10.
A note about "But I know that Apple now wants to reserve all two-character prefixes for themselves". As a personal preference I like to use the _ character to separate the prefix from the name, it works well for me. You might try something like:
-(DSManagedObject *)ds_copy; NS_RETURNS_RETAINED;
This would give you three characters, and arguably make the method name more readable.
Edit In response to link posted in comment.
However as Justin's answer to your original question says that can be broken.
With regards to attributes; I did not suggest using __attribute__((objc_method_family(copy))) I suggested using NS_RETURNS_RETAINED, which translates to :__attribute__((ns_returns_retained)). While the first example there won't even compile (as he says) using - (NSString *)string __attribute__((objc_method_family(copy))); it compiles with - (NSString *)string; NS_RETURNS_RETAINED; just fine.
Obviously also if the NS_RETURNS_.. are "hidden" from the compiler in separate the .ms or indirected in some other way and the compiler can't see the directives then it won't work. Because of this I would suggest putting the declaration for any methods that may cause the analyzer/compiler confusion in your main .h file (the one that imports all the others) to limit the chances that there will be an issue.
This is probably another thick, newbie question that will have everyone smacking their foreheads and going 'Duhhhhh!' BUT, after another long spell of reading and watching countless Brad Larson videos, I'm left perplexed at why delegation in general and CALayer delegation in particular seems to be such an enigmatic theme.
All the books and Dr Larson bang on about 'not sub-classing CALayers' unless you want a high degree of encapsulation but nowhere have I found a succinct and to-the-point example of the benefits that CALayer delegation can offer. Everyone seems to use either, the host view controller object as a, sort-of, perfunctory delegate or they shovel everything into the App delegate "as a brief example of what can be achieved".
I'm trying to learn "BEST PRACTICE" up-front - because I'm so new and because I don't want to develop any bad or slovenly programming traits - so I'm keen to examine each new step I take in minute detail. From what I can gather, a CALayer delegate class only has about 3 delegate-specific methods in it. These are 'displayLayer:', 'drawLayer:InContext:' and 'actionForLayer:ForKey:'. In my Opacity-generated Quartz stuff, I have used colour variables which I want to manipulate at runtime and do so without sub-classing CALayer. One of the side-effects of using Key-Value pairs is that there exists a class method called 'defaultValueForKey:' which describes the initial value of my colours according to the key value used to identify them. This is NOT (apparently) a CALayer delegate method. So how can I implement this code (which, after, all only sets a default value) without sub-classing CALayer? It seems that delegation is OK as long as you only need the few delegate-specific methods.
Could anyone explain why, when implementing delegation, the boffins at Apple didn't simply transpose the method-definition compilation unit from the class unit to the assigned delegate unit. e.g. Simply place an initial parameter in front of every method usually available in the class (or sub-class) by the phrase; 'forLayer: (CALayer *) TheRest: OfThe: method'? This way a simple switch or if-then stack could apply the usual method-ry of the class in one centralised object - the delegate.
As I said at the beginning, I'm probably missing something pretty basic but could anyone tell me how I implement all my key-value colour variable inits without sub-classing CALayer?
Thanks in advance,
V.V.
You're over thinking it all. As you mentioned, you're new to the platform. There are many idioms in Cocoa, but one of the idioms is a bit like Perl: "there's more than one way to do it".
Cocoa has a history of delegation because much of the time, you just need a method or two, and who wants the complexity of a zillion classes with few methods. Delegates let you work around that in a simple way.
So, basically rather than analyzing everything from the overall engineering point of view, just use the platform. Write some code. Write some code the "wrong way". Write lots of it.
Why? Because if it's the "wrong way", you will feel it yourself. You'll start cursing it in maintenance or whatever, and then you'll figure out the "right way". What is the "right way"? The way that feels better for YOU.
Most of these decisions have minimal impact on performance, etc., so don't worry about it. And because of that, it doesn't really matter which technique you choose.
Write code. Write lots of it. The more you write the more you'll get a feel as to when what technique is right, and which one is wrong. Or when the right way before now becomes the wrong way and should be refactored in to the new right way.
Because what's right or wrong now may not be later.
In response to a previous question on how to achieve a certain effect with Swing, I was directed to JDesktopPane and JInternalFrame. Unfortunately, scala.swing doesn't seem to have any wrapper for either class, so I'm left with extending it.
What do I have to know and do to make minimally usable wrappers for these classes, to be used with and by scala.swing, and what would be the additional steps to make most of them?
Edit:
As suggested by someone, let me explain the effect I intend to achieve. My program controls (personal) lottery bets. So I have a number of different tickets, each of which can have a number of different bets, and varying validities.
The idea is displaying each of these tickets in a separate "space", and the JInternalFrames seems to be just what I want, and letting people create new tickets, load them from files, save them to files, and generally checking or editing the information in each.
Besides that, there needs to be a space to display the lottery results, and I intend to evolve the program to be able to control collective bets -- who contributed with how much, and how any winning should be split. I haven't considered the interface for that yet.
Please note that:
I can't "just use" the Java classes, and still take full advantage of Scala swing features. The answers in the previous question already tell me how to do what I want with the Java classes, and that is not what I'm asking here.
Reading the source code of existing scala.swing classes to learn how to do it is the work I'm trying to avoid with this question.
You might consider Scala's "implicit conversions" mechanism. You could do something like this:
implicit def enrichJInternalFrame(ji : JInternalFrame) =
new RichJInternalFrame(ji)
You now define a class RichJInternalFrame() which takes a JInternalFrame, and has whatever methods you'd like to extend JInternalFrame with, eg:
class RichJInternalFrame(wrapped : JInternalFrame) {
def showThis = {
wrapped.show()
}
}
This creates a new method showThis which just calls show on the JInternalFrame. You could now call this method on a JInternalFrame:
val jif = new JInternalFrame()
println(jif.showThis);
Scala will automatically convert jif into a RichJInternalFrame and let you call this method on it.
You can import all java libraries directly into your scala code.
Try the scala tutorial section: "interaction with Java".
Java in scala
You might be be able to use the scala.swing source as reference e.g. http://lampsvn.epfl.ch/svn-repos/scala/scala/trunk/src/swing/scala/swing/Button.scala
What sort of scala features are you trying to use with it? That might help in coming up with with an answer. I.e. - what is it you're trying to do with it, potentially in Java? Then we can try to come up with a nicer way to do it with Scala and/or create a wrapper for the classes which would make what you're trying to do even easier.
In JRuby, you could mix in one (or more) traits into JDesktopPane or JInternalFrame instead of extending them. This way you wouldn't have to wrap the classes but just use the existing objects. As far as I know, this is not possible with Scala traits.
Luckily, there is a solution, almost as flexible as Ruby's: lexically open classes. This blog article gives an excellent introduction, IMHO.