Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I have been trying to learn scala. One thing that I have noticed is the quality of the docs. They seem to miss out on a lot of methods. Is this intentional? I feel like I am missing something because they can't be this bad.
For example:
Blog post on reading files with scala. The blog post recommends using a scala.io.Source.fromFile(..) method to read a file. It provides an iterator. Looks very nice to use. I want to get a better understanding of the class, so I go to the scala docs on scala.io.Source.
No where in the docs does it show the method for scala.io.Source.fromFile(..). When I go to my IDE, it does try to autocomplete Source.fromFile(..), and it even works in the code.
This happened to me before when I was trying to use scala's database api. Am I missing something? Is there a secret button that pulls up this method? Have I gone my whole life being blind without realizing it? Or are the scaladocs really this bad?
fromFile is not a method of class Source, it's a method of object Source. I.e. you can't write
val source: Source = ...
source.fromFile(...)
You are looking at the documentation for the class, which doesn't list the object's methods.
The link to the object's documentation is the circle with C near the class name at the top.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Recently My Project Manger has asked me to work on InterSystems Cache ObjectScript. Earlier i used to work as Java Developer (J2EE). So my question is how different is Cache from java. Comparison would be great to have.
Caché ObjectScript is very different from Java and has very little in common. It is more like dynamically typed compiled scripting language with meta language built in (class definitions) and with a large number of features you need to know to write the good code. All the code is compiled to a low-level (but pretty readable) so-called routine code and is processed by DBMS Caché and its application engine.
Take for example this reference. As you may notice, there are many weird symbols and structures like $, $$, $$$, ##class, &sql(...), &javascript<...>, #dim, $System, .#, $get, $zu(...), %, ^%, { ... }, ... (this list is big). Some of the language features are very unpredictable from the first glance. For example, function $get(...) looks like a fundtion but silently acts like a try/catch statement, as well as $data and some other system functions.
So prepare to work with InterSystems documentation! Also, recently developed InterSystems community is a great resource. And while Googling, you may find quite a few answers out of the internet, but just keep in mind to search with “intersystems” or “objectscript” keywords. But many things you won’t find there, and in this case you should use InterSystems docs or community to ask the questions. Once you will get used to the language (which for me took over 6 months), you will feel more confident in it.
Also it is worth mention that Caché ObjectScript is literally “dinosaur” language, which involves and upgrades over time. That’s why there are so many different features. Some of them you shouldn’t use anymore: for example, instead of writing code in routine, like people did before OOP concepths were introduced, you should use classes. ObjectScript’s JSON capabilities (ability to write JSON inside ObjectScript) was intoduced just approximately 1 year ago. And you may find a plenty of “prehistoric” code in Caché and should take it normally: it is a really huge ecosystem.
Hope this helps, happy hacking!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am CS student relatively new to Cocoa/CocoaTouch and I am trying to understand the nature of OS X/iOS dev. I understand the difference between dynamic and static languages.
Static languages have all variables bound to a type etc. Variables are bound during execution for dynamic etc.
However, when I am developing OS X apps I struggle to see the examples where dynamic functionality would change things? Can someone explain what someone explain what Obj-C can support that Swift fundamentally cannot when developing apps?
I have come across many cases where the lack of flexibility has forced me to refactor my code, but that's not what I am talking about, or am I confused?
Can someone explain what someone explain what Obj-C can support that Swift fundamentally cannot when developing apps
What I used to take advantage of in Objective-C was not so much dynamic typing as dynamic messaging. The whole messaging apparatus can be rejiggered at runtime, from simple key-value coding or performSelector to dynamic injection of methods into a class at runtime, method swizzling, and key-value observing.
You can do all those things in Swift, but only provided you are talking to Objective-C (i.e. this is an NSObject). That's because all of those things are actually done in Objective-C. You could not, for example, implement even the most basic key-value coding in pure Swift, in the absence of Foundation, as Swift has neither dynamic messaging nor true introspection.
From the point of view of practical app programming, however, I don't miss any of that. For one thing, I am always talking to Objective-C, because Cocoa is in Objective-C. For another thing, it turns out that most of these tricks weren't really necessary, and I've mostly found other ways to accomplish my practical goals. I do still use some key-value coding (especially to do tricks like store an arbitrary value inside a CALayer), but on the whole I've cut way back on my use of such stuff, mostly thanks to the fact that functions are first-class citizens in Swift.
As for dynamic typing, I don't miss it for an instant; changing to Swift has actually saved me from mistakes that I was making without even realizing it because of dynamic typing imposed on me by the APIs (e.g. the fact that objectAtIndex: returned an id — though, to be sure, this is less likely to trouble you today thanks to "lightweight generics").
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I really want to use PGM for an application that I'm working on for one my companies. That application will never be distributed, it's for internal use only. There is an implementation called OpenPGM and a (I believe) derivative work javapgm that implements the protocol. Both are licensed under the LGPL.
My question is if I read the source code for these libraries and use that knowledge to help create an Erlang PGM implementation, would that be considered a derived work? I would prefer to release my implementation under the BSD license, so I'm not trying to take something for nothing, but I want to play fair.
In short then:
Would / should my version be released under the LGPL?
If my company is using it internally only, would there be any restrictions on how it could use that library? (it would never be distributed outside the company).
Is it in the spirit of the LGPL license to do what I want to do?
Thanks in advance! :)
I don't think it would be a derived work unless there is a 1:1 correlation between lines of code in your thing and the open source code. We're not talking about a patent here, where the concept of the invention is important.
If it is only used internally then it doesn't have to be.
You could never be certain that it doesn't accidentally leak out or get shared or included in another project.
You should try to work with OpenPGM to make the Erlang interface that you need; then it is open source, other people may help maintain it for you, you get a free code review
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I just completed with one of my applications which is now ready to be tested. But before submitting my application I want to make sure I have used appropriate comments wherever required. Though I use comments in most of my applications but it is this time I have realized that my application is quite complex and thus for the purpose of reviewing the code again and for functional understanding I need proper commenting. I was also worried about the amount of commenting in my application.
What I am looking for are standard commenting practices we need to follow in IPhone development.
Kindly assist.
Good Comments say "why" you did something, not "what" you did.
I usually implement comments in the following situations, (this is by no means exhaustive), and any developer reviewing or debugging your application would appreciate them in these situations:
When I use a third-party or otherwise obscure library;
In deep-nested control structures when they cannot be avoided;
When implementing my own protocols in Obj-C (when they are not obvious);
And in general when something is not obvious to you and/or a potential reviewer
EDIT: And I also suggest implementing sparingly, if you did not get that from the post. It is annoying to read code that is near the over-commenting threshold. You do not want to feel like you are reading an introduction to programming book.
There is nothing special with regard to comments and iPhone development.
Personally I prefer readable (self-documenting) code over comments. That is, using meaningful method and variable names to make the purpose of the code understood. If it still can't be understood then comments might be useful, but don't make them too long. A problem with long comments is that they might fall out of sync with the sources and become misleading.
I think links to other sources of documentation are good, such as stackoverflow questions, bug databases, etc.
These, to me, are the golden principles:
Comments should never explain code (use self-explanatory code with proper names and indentation).
Don't insult the reader's intelligence with unnesseary comments
Comment by code block (if you need to explain a process, don't use seperate comments on each line of the code block).
When Im commenting my code, I act as if I had some half wit programmer sitting right next to me asking me "what does this code do, and why are you doing it?" Ill reply in a nutshell of an answer.
My response to him is what I comment.
// now that we got the data we need lets store it in the Settings Array
// check for NULL if null, change to None Selected
// make sure there is an object here so we dont crash
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
Does code like this (potentially) violate the iPhone Developer License Agreement?
Class clazz = NSClassFromString(#"WNEntity");
id entity = [clazz entityWithImage:#"Icon.png"];
SEL setPositionSelector = NSSelectorFromString(#"setPosition:");
objc_msgSend(entity, setPositionSelector, CGPointMake(200, 100));
I'm working on code that dynamically allocates classes from XML and calls methods on them via objc_msgSend. It's just very convenient constructing my objects that way but it worries me because i have no idea whether this is ok or violates the License by dynamically executing code or maybe even calling private (?) API functions. They wouldn't be documented if they were private, right?
Can someone shed some light on this? Have you had an App approved or rejected using code similar to the above?
I'm pretty sure that this is ok but i wan't to hear it from someone else! :)
If the method you're calling is documented, you're not violating the agreement. There's nothing wrong with using objc_msgSend(), because these "reflection" functions are fully documented.
You need to use a similar structure in order to support different versions of iOS (or a "universal" app that works on iPhone and iPad) so it should be fine.
One point, though: I'm not sure that you need to directly use objc_msgSend. Could you not use performSelector:withObject:afterDelay: or one of the other, similar methods of NSObject?