Discussions

I've created a simplified way of adding docking to your winForm applications.

FormRope.CodePlex.com

AndyC said:

What do you mean by "How do I access a file...." The result of the Renderer project is (presumably) a dll, so you can add a reference to the dll from the main engine project. You can't access individual source files that make up the renderer project, because the whole point of seperate projects is to isolate parts of an overall solution.

I thought it was possible to import a reference to another project in Visual Studio?

Solution Explorer -> Highlight A Project -> Right Click -> Add Project -> Then Add New / Add Existing Project

In the main project. add reference to the co-projects.

All Public Classes, Methods and Namespaces of the co-project are available.

A Injury from a lack of work? Was it from excessive thumb twiddling? or from standing and "sticking your Thumb up your a**"?

spivonious said:

AdamSpeight2008 said:

*snip*

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.

Yggdrasil said:

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

Have a workable solution (code below) for "Branded" that works in VS2010, lacks the syntactic sugar of the idea base.

Maybe someone can help to add that, so that

Dim _M As Double["Metres"]=100

Function(ByVal _Distance As Double["Meters"],ByVal _TimeTaken[Seconds])

is converted to

Dim _M As New Brand(of Double)(100,"Metres")

Function(ByVal _Distance As Brand(Of Double), ByVal _TimeTaken As Brand(Of Double))

  Contracts.Contract.RequiresAlways(_Distance.Brand.ToUpper = "METERS")
  Contracts.Contract.RequiresAlways(_TimeTaken.Brand.ToUpper = "SECONDS")

Respectively

The workable solution code

Module BrandedTest

 Sub Main()

   Dim dist As New Brand(Of Double)(100, "Meters")
Dim t As New Brand(Of Double)(9.98, "Seconds")
     Dim v1 As Brand(Of Double) = Test(dist, t)

 Dim v2 As Brand(Of Double) = Test(t, dist) 'Doesn't Compile which is great

  End Sub

Public Function Test(ByVal _Distance As Brand(Of Double), ByRef _TimeTaken As Brand(Of Double)) As Brand(Of Double)
    Contracts.Contract.RequiresAlways(_Distance.Brand.ToUpper = "METERS", "Distance value isn't in Metres")
    Contracts.Contract.RequiresAlways(_TimeTaken.Brand.ToUpper = "SECONDS", "TimeTaken value isn't in Seconds")
    Return New Brand(Of Double)(_Distance.Value / _TimeTaken.Value, "Speed (MperSec)")
  End Function

End Module

 Public Class Brand(Of T)
   Protected m_Value As T
   Public Property Value() As T
     Get
       Return m_Value
     End Get
     Set(ByVal value As T)
       m_Value = value
     End Set
   End Property
 
   Protected m_Name As String = ""
   Public ReadOnly Property Brand() As String
     Get
       Return m_Name
     End Get
   End Property
 
   Public Sub New(ByVal v As T, ByVal Name As String)
     m_Value = v
     m_Name = Name
   End Sub
 
  Shared Function SameBrand(ByVal _A As Brand(Of T), ByVal _B As Brand(Of T)) As Boolean
    Return _A.Brand.CompareTo(_B) = 0
  End Function
 End Class

Aliasing In VB.net

  Imports Metres = Double

 Imports Seconds = Double

 Imports Speed = Double

 Public Function CalcSpeed(ByRef d As Metres, ByRef s As Metres) As Speed

 Return d/s

 End Function

 Dim m As Metres=100

 Dim s As Seconds=9.98

 v1=CalcSpeed(m,s) OK but v1=CalcSpeed(s,m)  Compiles! Wrong

Sven Groot said:

*snip*

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.

Dim x As ANumber=99 : While x.IsPositive: Print Element(x) : x.Decrement ; End While

My point is that they already have the code for Arbitrary precision arithmetic (APA) It's not like starting from scratch.

I know A.P.A. are slow but it would have better to have had the choice to use it or not.

Regarding "Branded" I think you may have missed the important point about "Branded" Types, they are checked at Design/Compile Time not run time.

Dim Name1 As String["Name"]="Adam"

Dim Name2 As String["Name"]="Paul"

Dim Street1 As String["Street"]="Doe Road"

Dim String As String["Street"]="Doe Road"

Traditional if you wrote: If Name1=Street1 Then Compiler would let it through

With "Branded" Type: If Name1=Street1 Then  the Compiler would complain.

Dim TimeTaken As Double["Seconds"] = 10

Dim Distance As Double["Metres"]=5

Dim v1 As Double["SpeedMs"]

v1=Distance / TimeTaken 'Compiler Warning (Possible Issue): Division of Mismatched Branded Types.

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.

Idea 1: Numeric.ANumber

In .net 4.0 Microsoft is introducing the BigInteger Type. Why didn't they also add the an arbitary precision type as well?

They have shown previous they capability to implement one, as shown in the XP Powertoy PowerCalc. (Upto 512 digits).

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

To a end user; they enter a number, they ain't fussed wether it's a byte, a double or an integer.

Namespace: Numerics.Number / Numerics.ANumber ← My Preference

VB.Net Code Example:

Dim x As ANumber=123.567

Dim NewPrice As ANumber = ANumber.FromText(ProductPriceChange.NewPrice)

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.

VB.Net Code Example:

Dim CarSpeed As Double [Velocity] Note: Using Square Braces ← My Preference

Dim CarSpeed As Double {AsA Velocity} Note: Keyword "AsA"

Function ImpactSpeed(ByRef v1 As Double[Velocity], ByRef v2 As Double[Velocity] ) As Double[Velocity]

Dim Vi As Double[Velocity]

Vi=v1+v2

Return Vi

End Function

Intellisense could then be extended to have the capabilty show the coder all the "Branded" types.

Dim  MassOfThisPerson As Double[→Velocity ?]

In addition to letting the coder create a "brand" Microsoft could supply a predefined list of "Branded" types for example, covering SI units of measurement (Mass, Velocity)

What are your thoughts on these ideas?