Tag Info

New answers tagged

2

Not all features of a class are relevant to the type of its instances: Private methods, the constructor, the destructor (in C++), and the methods' implementations. This is not usually true. In a nominative type system, nothing about the type matters but the name (and where it exists in the hierarchy if you have subtyping). As the compiler goes through ...


1

Any field/method that a user of the class can access is part of the type, because all code using that type has to know it exists, whether it's static, how many arguments it takes and so on in order for code using it to compile properly. For instance, you'd have no way of knowing if Foo::field was valid code unless static int field (or something similar) was ...


9

It's the same function name, with the same arguments, but potentially different return types and implementations, because it's polymorphic. That means if it's called in a context expecting an (Int, MyWeirdCustomNumType) return type, it has to evaluate it twice, because the implementation of (+) in Int is completely different from the implementation of (+) ...


3

Unpopular opinion: You should usually not define a new type! Defining a new type to wrap a primitive or a basic class is sometimes called defining a pseudo-type. IBM describes this as a bad practice here (they focus specifically on misuse with generics in this case). Pseudo types make common library functionality useless. Java's Math functions can work ...


4

On the surface it looks like all you need to do is identify an operation. Additionally you say what an operation is supposed to do: to start the operation [and] to monitor its finish You say it in a way as if this is "just how the identification is used", but I would say these are properties describing an operation. That sounds like a type definition ...


8

I generally agree that many times you should create a type for primitives and strings, but because the above answers recommend creating a type in most cases, I'll list a few reasons why/when not to: Performance. I must refer to actual languages here. In C#, if a client ID is a short and you wrap it in a class - you've just created a lot of overhead: ...


4

Idea behind wrapping primitive types, To establish domain specific language Limit mistakes done by users by passing incorrect values Obviously it would be very difficult and not practical to do it everywhere, but it's important to wrap the types where required, For example if you have the class Order, Order { long OrderId { get; set; } string ...


27

Static type systems are all about preventing incorrect uses of data. There are obvious examples of types doing this: you can't get the month of a UUID you can't multiply two strings. There are more subtle examples you can't pay for something using the length of desk you can't make an HTTP request using someone's name as the URL. We may be tempted ...


6

No, you should not define types (classes) for "everything". But, as other answers state, it often is useful to do so. You should develop – consciously, if possible – a feeling or sense of too-much-friction due to the absence of a suitable type or class, as you write, test, and maintain your code. For me, the onset of too-much-friction is when I want to ...


50

I would use the scope as a rule of thumb: The narrower the scope of generating and consuming such values is, the less likely you have to create an object representing this value. Say you have the following pseudocode id = generateProcessId(); doFancyOtherstuff(); job.do(id); then the scope is very limited and I would see no sense in making it a type. But ...


122

Primitives, such as string or int, have no meaning in a business domain. A direct consequence of this is that you may mistakenly use an URL when a product ID is expected, or use quantity when expecting price. This is also why Object Calisthenics challenge features primitives wrapping as one of its rules: Rule 3: Wrap all primitives and Strings In ...


3

As with all tips, knowing when to apply the rules is the skill. If you create your own types in a type-driven language you get type checking. So generally that is going to be a good plan. NamingConvention is key to readability. The two combined can convey intention clearly. But /// is still useful. So yes, I would say create many own types when their ...


8

Do you think it is a good practice to wrap simple types in a class for safety reasons? Sometimes. This is one of those cases where you need to weigh the problems that may arise from using a string instead of a more concrete OperationIdentifier. What are their severity? What is their likeliness? Then you need to consider the cost of using the other ...


4

Hm, well for the first one this is because let's say f f was well typed. We're applying f so it has to be a function. Functions have the type f : A -> B for some A and B. Since f is also the argument, it must also be the case that f : A. This means that A = A -> B. Moreover since f = f f, the the type of f f is also the type of f. Since f f : B this ...


1

Another option is to add a rational number type. This is stored as two integers, which usually will need to be multi-precision, and can represent any floating point value including the result of an operation between floating point and a multi-precision integer. This way there is no loss of information. But there is a lot of work involved and should only be ...


1

As a start, if we begin to consider the actual quantities involved then some subcases might be handled easily. It might also depend upon the operation we want to do. MPI {+-} FLO FLO {+-} MPI If the FLO has a zero fractional part, then it can be converted to MPI losslessly. If it does have a fraction, then we probably want to keep the fraction and we ...



Top 50 recent answers are included