Consider the following function:
public function foo(bar1:int, bar2:uint, bar3:String, bar4:Boolean):void{}
What I want is to have the different types of data represented by custom named types which are essentially representing the original data types. In other words, I would like to proxy the data types and have a valid function as following:
public function foo(bar1:PAR_Bar1, bar2:PAR_Bar2, bar3:PAR_Bar3, bar4:PAR_Bar4):void{}
so PAR_Bar1 would proxy the int data type, PAR_Bar2 would proxy the uint data type, so on and so forth.
The reason I need this is because I'm using a debugger with a GUI that can run methods and allows changing function parameter values in real-time, the issue is that the debugger can't tell me what parameter I'm changing, it only displays the data type of a parameter. So if I need to change 10 different parameters all of type int, the debuggers display all of them as int and not by their names.
I think that if I use proxy types I can easily differentiate between parameters.
So, my question: Is it possible to proxy data types? I mean map specific data types to custom data types that would represent the base data types?
EDIT: I'm using the Monster Debugger and this is the window of a method called in real-time:
As you can see, I don't get the parameters' names but their type (int).
I would recommend you changed your debugger but since this is a proper question...
You can create a class just like any constant:
const PAR_Bar1:Class = uint;
Let's hope your debugger will identify this class and not its mother.
Not exactly sure what you are going to use this for but have you considered using an untyped variable definition?
public function foo(bar1:*, bar2:*, bar3:*, bar4:*):void{}
Then using this to get the class of the variables?
var PAR_Bar1:Class = Object(bar1).constructor;
EDIT: Ah ignore this one, re-read your question and realised this won't help you.
It seems that there are no ways of aliasing types.
Related
I was creating a function and I tried to increase the value of the parameter which was declared as Integer. But it said that the value of that parameter can not be reassigned. I am a beginner so if I am missing some concept please tell me.
Yes, in Kotlin function parameters can't be changed.
(However, if they refer to mutable objects, then those objects can change. For example, if you declared fun a(b: List<String>), then you could add another String to the List; but you couldn't set b to refer to a different List.)
This is different from Java, where parameters are variable (unless specified as final).
This behaviour was announced in Kotlin milestone M5.1, where it was explained as avoiding confusion (especially in constructors), and promoting good style.
See also this answer.
How do I make PhpStorm suggest input variables ?
In Java/C# and the like (with VS/Eclipse), when I have a function that receives enum-input-variable, like:
void func(SomeEnum var);
Whenever I type func(, the editor kindly suggests all the available enums (of type SomeEnum). I look for this same functionality in PHP, when I have a predefined set of input options (like DB's tables).
Maybe with the use of Intellilang or these # tags (PHPDocs ?) I can predefine such list ?
Currently you cannot limit the possible options for code completion in this regard: PHP simply has no such "thing" similar to Enum. The only limitation you can do is limit by expected parameter type (e.g. int variable will not be offered when parameter expects an array).
I think this will be the correct ticket to look for: http://youtrack.jetbrains.com/issue/WI-854 and maybe http://youtrack.jetbrains.com/issue/WI-3623
Kind of related (for array indexes completion): http://youtrack.jetbrains.com/issue/WI-3423
I was looking at some code of a fellow developer, and almost cried. In the method definition there are 12 arguments. From my experience..this isn't good. If it were me, I would have sent in an object of some sort.
Is there another / more preferred way to do this (in other words, what's the best way to fix this and explain why)?
public long Save (
String today,
String name,
String desc,
int ID,
String otherNm,
DateTime dt,
int status,
String periodID,
String otherDt,
String submittedDt
)
ignore my poor variable names - they are examples
It highly depends on the language.
In a language without compile-time typechecking (e.g. python, javascript, etc.) you should use keyword arguments (common in python: you can access them like a dictionary passed in as an argument) or objects/dictionaries you manually pass in as arguments (common in javascript).
However the "argument hell" you described is sometimes "the right way to do things" for certain languages with compile-time typechecking, because using objects will obfuscate the semantics from the typechecker. The solution then would be to use a better language with compile-time typechecking which allows pattern-matching of objects as arguments.
Yes, use objects. Also, the function is probably doing too much if it needs all of this information, so use smaller functions.
Use objects.
class User { ... }
User user = ...
Save(user);
It decision provides easy way for adding new parameters.
It depends on how complex the function is. If it does something non-trivial with each of those arguments, it should probably be split. If it just passes them through, they should probably be collected in an object. But if it just creates a row in a table, it's not really big deal. It's less of a deal if your language supports keyword arguments.
I imagine the issue you're experiencing is being able to look at the method call and know what argument is receiving what value. This is a pernicious problem in a language like Java, which lacks something like keyword arguments or JSON hashes to pass named arguments.
In this situation, the Builder pattern is a useful solution. It's more objects, three total, but leads to more comprehensible code for the problem you're describing. So the three objects in this case would be as such:
Thing: stateful entity, typically immutable (i.e. getters only)
ThingBuilder: factory class, creates a Thing entity and sets its values.
ThingDAO: not necessary for using the Builder pattern, but addresses your question.
Interaction
/*
ThingBuilder is a static inner class of Thing, where each of its
"set" method calls returns the ThingBuilder instance being worked with
while the final "build()" call returns the instantiated Thing instance.
*/
Thing thing = Thing.createBuilder().
.setToday("2012/04/01")
.setName("Example")
// ...etc...
.build();
// the Thing instance as get methods for each property
thing.getName();
// get your reference to thingDAO however it's done
thingDAO.save(thing);
The result is you get named arguments and an immutable instance.
I was wondering, why do static Create methods exist?
For instance, why use this code:
System.Xml.XmlReader reader = System.Xml.XmlReader.Create(inputUri);
over this code:
System.Xml.XmlReader reader = new System.Xml.XmlReader(inputUri);
I cannot find the rationale for using one over the other, and can't find any relation between classes who use this construct over the other.
Can anyone shed some light on this?
XmlReader is an abstract class. You cannot instantiate it.
Providing a Create method is an instance of the factory pattern. Depending on the specified arguments a different implementation of XmlReader is chosen and returned. For example, there are validating and non-validating XmlReader implementations in the .NET framework.
A more general answer...
The reason people like these kinds of methods, known as "static factory methods", is because you can give them a name (as opposed to constructors). So if you need three different constructors, you can instead create static factory methods which have names relevant to their use.
Another reason is that a factory method doesn't really need to create new objects - it can return the same one over and over if need be.
Because it can actually create and object of derived type that you have no access to or return an abstract class (as dtb answered). This is factory method pattern.
A constructor can only be used to create instances of one specific class, while a static Create method can create an instance of different classes depending on the input.
In the case of the XmlReader class the Create method will return an XmlDictionaryReader, XmlTextReader, XmlValidatingReader or XmlNodeReader, depending on which overload you use and what parameters you send to it.
This pattern allows the XmlReader class to provide you with instances of derived classes tailored to the parameters you passed to Create. Note in particular the overloads that accept an XmlReaderSettings object. A different XmlReader subclass can be returned to you depending on your settings.
A better example is WebRequest.Create(url). Depending on the URL you pass, you may receive an HttpWebRequest, an FtpWebRequest, etc.
Because you don't have to commit to the exact class of object you get. Constructors can only construct objects from exactly one class.
Because you can give the method a meaningful name, e.g. BigInt.probablePrime(). Constructors can only have the same name as the class.
Because you can have more than one factory method for the same parameter type combination, e.g. Point.fromPolarCoords(int, int) and Point.fromCartesianCoords(int, int), but there can be only one constructor Point(int, int).
(A much more detailed answer is given in Bloch's 'Effective Java'.)
Sometimes they exist as a form of self-documentation. I have a db access component that I can instantiate either with a connection string or the name of the connection in the config file. Both of these methods take strings as a parameter so they cannot be differentiated by arguments alone. So I created a FromConnectionString(string) factory method and a FromConnectionName(string) factory method. This nuance would entirely be lost by a new Foo(bool, string) line.
The idea is that this way they can change the implementation of XmlReader and not break any user code (e.g. they can change the actual type that is returned from the Create method).
I personally don't like this approach, because it creates an inverse relationship in the XmlReader class hierarchy. Maybe they thought that the Factory pattern is an overkill?
To encapsulate object creation.
I wonder if you think that there is a need to refactor this class.( regarding separation of concern)
publi class CSVLIstMapping<T>
{
void ReadMappingFromAttirbutes();
void GetDataFromList();
}
ReadMappingFromAttributes - Reads the mapping from the type T and stores it in the class. Has a name of the list to use and a number of csvMappingColumns which contains the name of the property to set the value in and the name of csvcolumns.
GetObjectsFromList - uses a CVSListreader ( which is passed in via the constructor) to get the data from all row's as KeyValuePair ( Key = csvcolumnName , value = actually value) and after that it uses the mappinginformation( listname and csvMappingColumns ) to set the data in the object.
I cant decide if this class has 2 concerns or one. First I felt that it had two and started to refactor out the conversion from rows to object to another object. But after this it felt awkward to use the functionality, as I first had to create a mappingretriver, and after that I had to retrive the rows and pass it in together with the mapping to the "mapper" to convert the objects from the rows
/w
Sounds like two concerns to me: parsing and mapping/binding. I'd separate them. CSV parsing should be a well-defined problem. And you should care about more than mere mapping. What about validation? If you parse a date string, don't you want to make sure that it's valid before you bind it to an object attribute? I think you should.
Rule of thumb: if it's awkward, it's wrong.
I have to say I'm finding it hard to understand what you've written there, but I think it's likely that you need to refactor the class: the names seem unclear, any method called GetFoo() should really not be returning void, and it may be possible that the whole ReadMappingFromAttribute should just be constructor logic.