Alla numeriska datatyper samt datum har numera två properties som heter MinValue och MaxValue, och de är ju åtminstonde ur användarens (programmerarens) synvinkel konstanter. Men ändå kan man inte använda dessa som konstanter i vissa sammanhang :
<code>
' Ger fel : Error 1 Constant expression is required.
Public Sub Test(Optional Byval datum As Date=Date.MinValue)

End Sub
</code>
Det går heller inte att komma runt genom att deklarera en egen konstant :
<code>
Public Const MINVALUE As Date = Date.MinValue
</code>
Detta ger samma fel.

Kan någon förklara varför det är så här? Vad är den bakomliggande orsaken till detta? Är inte MinValue och MaxValue deklarerade som konstanter "internt" i datatypen? Irriterande är det i alla fall, men om jag vet varför så kanske jag kan släppa detta :-)

[Edit: La detta ".Net framework" eftersom samma problematik finns i C#]

Hej Per!

Detta fungerar i C# iaf.
<b>Console.WriteLine("Int32 = {0} DateTime = {1}", Int32.MinValue, DateTime.MinValue);</b>
Går lika bra att tilldela variabler också.
T.ex.
<b>int i = Int32.MinValue;
DateTime dt = DateTime.MinValue;
Console.WriteLine("i = {0} dt = {1}", i, dt);</b>

//Håkan

Well, dina exempel är inte samma sak som de jag visade. Dock har ju c# inte optional parameters så där har man ju inte det ena problemet men du kan fortfarande inte deklarera en konstant så här :

private const System.DateTime date = System.DateTime.MinValue;

Anledningen att man vill undvika att göra det till konstanter i frameworks är att konstanter tilldelas sitt värde vid compiletime. dvs värdet kompileras in i din assembly.

när någon sedan använder din assembly och använder din konstant , så kommer konstantens värde kompileras in i även denna assembly.

om du sedan släpper en ny version av din assembly , där du ändrar värdet på din konstant.
då skulle man inte kunna byta ut din gamla assembly mot din nya assembly i användarens app eftersom dennes app har det gamla konstantvärdet hårt inkompilerat i sig och skulle då kunna resultera i div buggar när det värdet inte längre stämmer med konstanten i din assembly.

dvs , user appen skulle behöva rekompileras varje gång du ändrar dina konstanter i ditt framework.


samma sak gäller .net som framework.
säg att .net framework 3 skulle ha större range för sina datetime typer , då skulle gamla apps inte längre fungera med det nya frameworket.


använder man statiska fält istället så får man inte problem med de bitarna eftersom värdena i användarens app inte längre kommer kompileras in direkt i koden utan hämtas från ditt framework varje gång de behövs.
(tror det här står i ms guidelinen för framework design )


//Roger

Tack för den förklaringen, och när jag läser detta så ringer det en klocka någonstans. Jag känner igen det här resonemanget så jag har nog hört det förut men glömt bort det. Nu kanske jag kan sova lugnt om nätterna :-)