Pseudo-Constants
Sometime you need a Constant that is calculated at run-time.
So how would you do it?
Sometime you need a Constant that is calculated at run-time.
So how would you do it?
Spoiler
4 Comments On This Entry
Page 1 of 1
lucky3
20 October 2012 - 12:23 AM
Interesting, as always Adam. I have a question about class example. Why are there shared members? You need instance of the class to use it, so wouldn't it be the same, if you just have:
How do you use Shared Sub New from outside?
'Public Shared ReadOnly Zero As Example
Public ReadOnly Value As Integer
'Shared Sub New()
' Zero = New Example(0)
'End Sub
Public Sub New(Value As Integer)
Me.Value = Value
End Sub
End Class
How do you use Shared Sub New from outside?
lucky3
21 October 2012 - 01:53 PM
You got my attention now, with Color there! :)
I think there's no need for shared constructor, because you can have the same effect with (let's build on this color example):
and you can just use it: Dim x1 = Colors.Red
If you use shared constructor, then the class would look something like:
In each case, what bothers me, is when you use variable x1 from declaration example above, you have all the shared fields available, and it is somehow strange to have something like: Dim x1 = Colors.Red.White.Yellow. But then again, the same is with "real" Color structure. You can have Dim red As System.Drawing.Color = Color.Red.Violet.Blue.Black.Turquoise.Yellow (and you have Yellow instead of Red). I didn't know that System.Drawing.Color uses the same principle, and I was shocked, when I looked at "live" variable red, and saw all other colors available in it. So I went with another line of code: Dim black = red.Black, and besides a warning, it works. Is there no better way of having all the predefined specific color values with names inside a class/structure, and when used "live", have just those properties available, as one would expect and need to use? If programmer declares Dim red As System.Drawing.Color = Color.Red, probably wouldn't expect to see and use red.Black, because in my opinion, it doesn't make much sense.
I think there's no need for shared constructor, because you can have the same effect with (let's build on this color example):
Public Class Colors
Public ReadOnly A As Byte
Public ReadOnly R As Byte
Public ReadOnly G As Byte
Public ReadOnly B As Byte
Public ReadOnly Name As String
Public Sub New(ByVal red As Byte,
ByVal green As Byte,
ByVal blue As Byte,
Optional ByVal alpha As Byte = 255,
Optional colorName As String = "")
A = alpha
R = red
G = green
B = blue
Name = colorName
End Sub
Public Shared ReadOnly White As New Colors(255, 255, 255, 255, "White")
Public Shared ReadOnly Yellow As New Colors(255, 255, 0, 255, "Yellow")
Public Shared ReadOnly Red As New Colors(255, 0, 0, 255, "Red")
Public Shared ReadOnly Gray As New Colors(128, 128, 128, 255, "Gray")
Public Shared ReadOnly Purple As New Colors(128, 0, 128, 255, "Purple")
Public Shared ReadOnly Green As New Colors(0, 128, 0, 255, "Green")
Public Shared ReadOnly Blue As New Colors(0, 0, 255, 255, "Blue")
Public Shared ReadOnly Brown As New Colors(128, 0, 0, 255, "Brown")
Public Shared ReadOnly Black As New Colors(0, 0, 0, 255, "Black")
End Class
and you can just use it: Dim x1 = Colors.Red
If you use shared constructor, then the class would look something like:
Public Class ColorsWithSharedConstructor
Public ReadOnly A As Byte
Public ReadOnly R As Byte
Public ReadOnly G As Byte
Public ReadOnly B As Byte
Public ReadOnly Name As String
Public Shared ReadOnly White As ColorsWithSharedConstructor
Public Shared ReadOnly Yellow As ColorsWithSharedConstructor
Public Shared ReadOnly Red As ColorsWithSharedConstructor
Public Shared ReadOnly Gray As ColorsWithSharedConstructor
Public Shared ReadOnly Purple As ColorsWithSharedConstructor
Public Shared ReadOnly Green As ColorsWithSharedConstructor
Public Shared ReadOnly Blue As ColorsWithSharedConstructor
Public Shared ReadOnly Brown As ColorsWithSharedConstructor
Public Shared ReadOnly Black As ColorsWithSharedConstructor
Shared Sub New()
White = New ColorsWithSharedConstructor(255, 255, 255, 255, "White")
Yellow = New ColorsWithSharedConstructor(255, 255, 0, 255, "Yellow")
Red = New ColorsWithSharedConstructor(255, 0, 0, 255, "Red")
Gray = New ColorsWithSharedConstructor(128, 128, 128, 255, "Gray")
Purple = New ColorsWithSharedConstructor(128, 0, 128, 255, "Purple")
Green = New ColorsWithSharedConstructor(0, 128, 0, 255, "Green")
Blue = New ColorsWithSharedConstructor(0, 0, 255, 255, "Blue")
Brown = New ColorsWithSharedConstructor(128, 0, 0, 255, "Brown")
Black = New ColorsWithSharedConstructor(0, 0, 0, 255, "Black")
End Sub
Public Sub New(ByVal red As Byte,
ByVal green As Byte,
ByVal blue As Byte,
Optional ByVal alpha As Byte = 255,
Optional colorName As String = "")
Me.A = alpha
Me.R = red
Me.G = green
Me.B = blue
Me.Name = colorName
End Sub
End Class
In each case, what bothers me, is when you use variable x1 from declaration example above, you have all the shared fields available, and it is somehow strange to have something like: Dim x1 = Colors.Red.White.Yellow. But then again, the same is with "real" Color structure. You can have Dim red As System.Drawing.Color = Color.Red.Violet.Blue.Black.Turquoise.Yellow (and you have Yellow instead of Red). I didn't know that System.Drawing.Color uses the same principle, and I was shocked, when I looked at "live" variable red, and saw all other colors available in it. So I went with another line of code: Dim black = red.Black, and besides a warning, it works. Is there no better way of having all the predefined specific color values with names inside a class/structure, and when used "live", have just those properties available, as one would expect and need to use? If programmer declares Dim red As System.Drawing.Color = Color.Red, probably wouldn't expect to see and use red.Black, because in my opinion, it doesn't make much sense.
Page 1 of 1
|
|



4 Comments








|