Note: Number.FromText can accept strings, or any control that has text propertity, etc,

ThisNumber.Increment

ThisNumber.Decrement

While ThisNumber.IsPositive (Note: IsPositive, Zero is classified as a positive.)

To me this further enhances the readabilty of the codesource.

For it to be as useful as the standard base class types, it would require to have the full functionality of System.Math.

Or its own NameSpace: Numeric.ANumber.Math / Numerics.Math

Idea 2: "Branded" Types

To have the ability to "brand" an instance of a numeric type (BaseClass & Numeric) as of belong to a particular user-define "collection" or unit.

Think of it as an opposite to Generics but a type gets "Branded".

Then Functions, Methods, etc. that take "branded" type only accept those "branded types".Saving the coder have to implement explicitly as new class. Also it would let enable the capabilty of being checked at design / compile time. Minimising and catching
some of the basic human errors. I.e. Confusing Feet & Inchs with metres.

While ThisNumber.IsPositive (Note: IsPositive, Zero is classified as a positive.)

How is that more readable or more clear than just "While ThisNumber >= 0"?

And making IsPositive include 0 is just weird and counter-intuitive. If you must have a property like that, at least call it IsNotNegative if it's meant to include zero (precedent: XSD data types can have an isPositive constraint (larger than zero) or isNotNegative
constraint (larger than or equals zero)).

How is that more readable or more clear than just "While ThisNumber >= 0"?

And making IsPositive include 0 is just weird and counter-intuitive. If you must have a property like that, at least call it IsNotNegative if it's meant to include zero (precedent: XSD data types can have an isPositive constraint (larger than zero) or isNotNegative
constraint (larger than or equals zero)).

AdamSpeight2008 said:

My reasoning is this, if it as extracted and available, coders wouldn't have to worry about parsing into a particalur type.

Well, they would. Arbitrary precision arithmetic is slow, it's not something you'd want to be
using all the time. I'm not saying it wouldn't be a good addition, but I'm not sure it's needed all that much. It certainly isn't (or shouldn't be) a general purpose solution to storing numbers.

"Branding" - Not sure this really gives you much over inheritance, except it the case of sealed classes perhaps. It's probably something that you could do with Attributes in the rare cases that it really mattered.

How is that more readable or more clear than just "While ThisNumber >= 0"?

And making IsPositive include 0 is just weird and counter-intuitive. If you must have a property like that, at least call it IsNotNegative if it's meant to include zero (precedent: XSD data types can have an isPositive constraint (larger than zero) or isNotNegative
constraint (larger than or equals zero)).

How is that more readable or more clear than just "While ThisNumber >= 0"?

And making IsPositive include 0 is just weird and counter-intuitive. If you must have a property like that, at least call it IsNotNegative if it's meant to include zero (precedent: XSD data types can have an isPositive constraint (larger than zero) or isNotNegative
constraint (larger than or equals zero)).

While ThisNumber>=0

To me this is comparing ThisNumber's value with 0 (A potentially expensive depending how the comparater was coded).

While ThisNumber.IsPositive

Whereas ths is a check of the sign of the number (Testing if something is set), There is nothing stopping adding .IsNegative or .Zero

Why I include 0 as a positive number? I was thinking about collections indexs. Consider the printing contents of collection.

One Possible way to dismiss the Compiler Warning. Is to extend "Branded" type so rules apply rules them.

Public Brands

Double[Metres]

Double{Seconds]

Double[Speed_MperS]

End Brands

Public BrandRules

Double[Speed_MperS] :=Double[Metre] / Double[Seconds]

End BrandRules

So by adding the above, to warning vanishes, but v1=TimeTaken / Distance throws an warning.

I think what you're after with your "branded" types is some kind of Strong-Typed Aliasing which echos a particular use case of C's #DEFINE blocks.

C# already allows the aliasing of types, but not in any meaningful way (You can already do "using Metre = System.Int32;" and then use Metre as if it were Int32). Pop an email down to the compiler folks if you think you've got a case.

I like the Branded types idea, although I prefer the name Alias or Typedef or something like that. I like the idea because it's like a simple contractual interface, not of syntax but of
intent. This is the reason I don't like using generic Tuple<X,Y> and prefer to subclass it - explicitness.

I like the Branded types idea, although I prefer the name Alias or Typedef or something like that. I like the idea because it's like a simple contractual interface, not of syntax but of
intent. This is the reason I don't like using generic Tuple<X,Y> and prefer to subclass it - explicitness.

That's the idea a simple contractual Interface to express an intent, which in case it could do with a different name.

I think changing it from Brand(Of to Use(Of
should make it clearer , as its designed to check the intend useage..Brand => .DefinedAs

That's the idea a simple contractual Interface to express an intent, which in case it could do with a different name.

I think changing it from Brand(Of to Use(Of
should make it clearer , as its designed to check the intend useage..Brand => .DefinedAs

What happens if you want to change an address to an array of 3 strings? String[address] no longer makes sense then.

I also think the whole idea isn't saving anything. The variable name should tell me what the value is, not the type. If I see speed = distance / time, I say "yep, makes sense." If I see speed = time / distance, I don't need the compiler to tell me something
is wrong.

What happens if you want to change an address to an array of 3 strings? String[address] no longer makes sense then.

I also think the whole idea isn't saving anything. The variable name should tell me what the value is, not the type. If I see speed = distance / time, I say "yep, makes sense." If I see speed = time / distance, I don't need the compiler to tell me something
is wrong.

"What happens if you want to change an address to an array of 3 strings? String[address] no longer makes sense then."

Dim Adresss(2) As String[Address]

"If I see speed = time / distance, I don't need the compiler to tell me something is wrong."

You completely missed the the point. At the moment you can a have a function with parameters of the
same type.

You could unknowning supply the them in the wrong. and you won't know you had until you ran it where the program performs incorrectly. Whereas if you "Branded" the instantion of the types it would have bean caught at compile time.

Function Foo(Byval A As Double, ByVal B As Double) As Boolean

End Function

' "Branded"

Function Foo(ByVal A As Double[Type_A], ByVal B As Double[Type_B]) As Boolean

End Function

Dim A As Double

Dim B AS Double

Dim AB As Double[Type_A]

Dim BB As Double[Type_B]

All the variable-based input combinations of variable iputs that can be supplied to the Functon Foo

Foo(A,A) Foo(A,B) Foo(A,AB) Foo(A,BB)

Foo(B,A) Foo(B,B) Foo(B,AB) Foo(A,BB)

Foo(AB,A) Foo(AB,B) Foo(AB,AB) Foo(AB,BB)

Foo(BB,A) Foo(BB,B) Foo(BB,AB) Foo(BB,BB)

With "Brand" types only the Bolded combination is allowed, without them all are all valid inputs.

Thread Closed

This thread is kinda stale and has been closed but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.