This question already has answers here:
How can I build an enum with Dart? [duplicate]
(4 answers)
Closed 8 years ago.
A simple question here :) I'm really happy to see a new feature in the dart language. But I just realized that I kind of never use enumeration.I don't know if there is a discussion somewhere about that but.
What is the pros and cons of this feature in terms of code writing (seems shorter), performance,etc?
Cheers
If I understand it correctly an enum is like a class with const members and some useful methods. Given that cost members are resolved by the compiler using an enum should not incur in any performance hit.
In terms of "code writing" enums are good candidates to replace classic const or static enumerations or, even better, hard-coded constants.
Related
This question already has answers here:
What is Facades used in Laravel?
(3 answers)
Closed 4 years ago.
Can you please describe elaborately about Facade?
A Facade is an alias to classes that are available in the application's service container, these classes can be Laravelor vendor package classes. Facades are used because they provide a terse, memorable syntax that allows us to use Laravel/Vendor features without remembering long class names.
In short Facades allow you to use fro example JWTAuth::getToken(), instead of having to type out Tymon\JWTAuth::getToken() in full, increasing code readability.
[read More][1][1]: https://laravel.com/docs/5.5/facades
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 5 years ago.
Improve this question
I noticed that the Smalltalk language has no concept of private/protected methods. All methods are public. Coming from a Java/C++ background, I've thought of this as a fundamental weakness in the language as any application created in Smalltalk would be completely open to manipulation. I guess you could rely on naming conventions to document the public API and prefix methods to indicate them as private (I believe Squeak does this), but it's still completely open.
Are there any benefits to this approach over having explicit access modifiers to control
access to method invocations?
Indeed, the Smalltalk way is to put private methods in the 'private' category. This indicates that you shouldn't use these methods, but of course doesn't enforce this.
This is by design - it's a feature, not a bug. Smalltalk was designed from the beginning precisely to be an open system.
Some advantages:
If I simply have to - maybe the library designer didn't foresee a need to expose some particular thing I simply have to have - I can still call those private methods. Obviously, this isn't something one does lightly: rather, judiciously, cautiously, knowing that it's a tactical solution.
Language simplicity.
(As per Alexandre Jasmin's comment) Smalltalk makes no distinction between what you, the programmer, can do and what the language/environment can do. That means that Smalltalk-the-image exposes all the things needed for you to build your own inspectors/debuggers/whatever without having to supply special tools using we-can-do-this-but-you-can't techniques.
Private and protected methods are in fact a significant weakness of languages like c++, java and c#. They basically say to their users: I don't want to learn and evolve. The consequence of that (and a lot more early binding) is that those languages require much more BDUF and are thus far less usable for a modern (agile) development process.
The first question is what private/protected access modifiers are about? Fundamentally, it is not about safety or security. It is about exposing the right interface to the user. Starting from that, it makes little difference between having categories protected/private and a language construct specifically for that.
I would even say that having private/protected visibility modifier brings more complexity to the problem than it actually solves.
Besides that, I don't think that private/protected visibility is a good answer to this problem
At the least, Smalltalk should have the textual convention that method names that begin with 'underscore' are verboten to call outside of the objects themselves. Unfortunately, I don't think that 'underscore' is allowed as the first character of a method name.
This question already has answers here:
Closed 10 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Possible Duplicate:
Advantages of using forward
Could someone please explain to me what perfect forwarding is about?
http://www.justsoftwaresolutions.co.uk/cplusplus/rvalue_references_and_perfect_forwarding.html
Why is this useful? Well, it means that a function template can pass its arguments through to another function whilst retaining the lvalue/rvalue nature of the function arguments by using std::forward. This is called "perfect forwarding", avoids excessive copying, and avoids the template author having to write multiple overloads for lvalue and rvalue references.
Quoting Session Announcement: Adventures in Perfect Forwarding:
Perfecting forwarding is an important C++0x technique built atop
rvalue references. It allows move semantics to be automatically
applied, even when the source and the destination of a move are
separated by intervening function calls. Common examples include
constructors and setter functions that forward arguments they receive
to the data members of the class they are initializing or setting, as
well as standard library functions like make_shared, which
“perfect-forwards” its arguments to the class constructor of whatever
object the to-be-created shared_ptr is to point to.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Placement of the asterisk in Objective-C
I'm new to XCode, coming from C#. What is the difference between the two following syntax examples, specifically the location of the asterisk?
UITabBarItem* tabBarItem
and
UITabBarItem *tabBarItem
When do you use one syntax over the other?
Both mean the same. There is no difference between the two and it is a matter of preference. I personally prefer the second way because it looks cleaner when have multiple pointers.
UITabBarItem *tabBarItemOne, *tabBarItemTwo ; // Looks cleaner :)
than
UITabBarItem* tabBarItemOne, *tabBarItemTwo ;
There is no difference, just preference. Both declare a pointer to a UITabBarItem.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Foundations of F# and Expert F# are probably the two most prevalent books used to learn f#.
Both were written at the time of the 1.9.2/1.9.3 releases.
The website for the Expert book has some errata and details some of the changes in the 2008 CTP release which were relatively minor.
However the CTP release for the 2010 beta (and the corresponding 2008 compatible release) 1.9.6.16 changes much more.
Since the MSDN documentation is largely non existent, especially in terms of changes and data is scattered around blogs I am finding it harder and harder to rely on the current books (especially the expert one) since the f# landscape has shifted too much underneath it.
This question seeks to provide a (hopefully) comprehensive list of those areas which have changed and short details/links to further reading on how to deal with this.
As the basis for this I have added some issue which impacted myself.
The previously linked blog post lists many of the changes in terse form and is a good place to start but it doesn't cover everything by any means.
Attempting to keep to a specific aspect per answer would be sensible since this will make reading it easier.
In specific question form:
What changes have occurred to f# from 1.9.6.3 to 1.9.6.16 that render previous examples (especially dead tree documentation not amenable to easy correction) incorrect or deprecated and what remedial actions are possible.
The signature of Array.sort changed; it used to be in-place, whereas now it returns a fresh array and Array.sortInPlace sorts in place. (That's been a minor problem-point for customers; most other library-renames issues deprecation warnings that steer you in the right new direction, but in this case the function still works, but has a new signature, which can make this difficult to diagnose at-a-glance.)
http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/FSharp.Core/Microsoft.FSharp.Collections.Array.html
A number of books were written before FSharp.PowerPack.dll was split out of FSharp.Core.dll, so for many examples you need to ensure you've added a reference to the powerpack to gain access to certain library functions.
See also http://blogs.msdn.com/dsyme/archive/2008/08/29/detailed-release-notes-for-the-f-september-2008-ctp-release.aspx
Events
Expert F# Chapter 8 section: Events and Wiring
IEvent is entirely deprecated. Instead the various functions are defined on Event instead.
There is no longer any need to use create_HandlerEvent to make a completely compatible .Net event (one consumable from, say c# easily) instead you use the CLIEvent attribute.
If you make your event via DelegateEvent<T> then the resulting event is usable without requiring any reference to the FSharp.Core dll.
If you use Event<T> then you must include a reference to the FSharp core to be able to use it.
Naming convention changes
removal of most '_' within function names
removal of deprecated functions
Specific examples and their resolutions
List
reduce_left to reduce
Seq
sort_by to sortBy
group_by to groupBy
init_finite to init
Several functions including cons and generate_using removed
Array
scan1_left to scanReduce
reduce_left to reduce
Multiple types have moved from being part of the dedicated F# runtime (child namespace of Microsoft.FSharp, in assembly FSharp.Core):
bigint now an alias for System.Numerics.BigInteger.
Tuple is now System.Tuple
#light
#light is the default, as a result some examples online will not compile.
This has a relatively minor impact since most examples used #light anyway.
Syntax changes
with member ... and support removed. Use explicit member this.Foo for each
1.9.4 changes
the change to Symmetric Operator Overloading.
subtle changes to the handling of nulls with boxing and option types