Vista - What's the correct way do design an Exif image information cmdlet?

Hi,

I wonder if there are any guidelines for how to design objects that may or
may not have a specific property.

Take an image with exif-information: Should the cmdlet append properties to
a FileInfo object, one for each Exif property in some image file?

In exif, there are for example some properties that represtents the time an
foto was taken.
This could be represented as a DateTime. The problem is that the property is
optional in EXIF.
If represented as a string, you can allways return null or String.Empty, but
then you lose all the goodness of the strong typing.

Looking for guidance or best practices!

Regards,

/Staffan

"Staffan Gustafsson" wrote:

> This could be represented as a DateTime. The problem is that the property is
> optional in EXIF.
> If represented as a string, you can allways return null or String.Empty, but
> then you lose all the goodness of the strong typing.

Uhh, why do you think a DateTime property can't be null?
If a String can be null, any other object should be able to be null, too.

--
greetings
dreeschkind

As a general rule, PowerShell is loose about missing values. e.g if you
specify a value that is not there, it returns a null instead of complaining.
In the latest release, we've added a the ability to say
Set-PSDebug -STRICT
This will throw an exception if you try to access a variable that does not
exist but it still lets you access properties that don't exist (we'll deal
with this an other features for -STRICT in V2).

As such, you can either add the properties and give then null values or NOT
add the properties. There are 2 considerations here:
1) SETTING. If you ever want to SET the values, then you should add them
and give them null properties. Setting a property that does not exist
causes an exception.
2) Resource consumption. You'll want to look at how many null properties
you'll have in the average case. If that is a lot, you might consider not
adding them.

--
Jeffrey Snover [MSFT]
Windows PowerShell Architect
Microsoft Corporation
This posting is provided "AS IS" with no warranties, no confers rights.

In the .NET type system, a DateTime is a ValueType, allocated on the stack,
not on the garbage collected head.

The only way you can get a reference to a DateTime is to box it, but then
you lose the strong typing.


PS > [string] $a=$null
[C:\NeoCode\N2]

PS > [DateTime] $a=$null
Cannot convert null to type "System.DateTime".
At line:1 char:14
+ [DateTime] $a= <<<< $null

/Staffan

"dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
news:039BA966-540F-415A-ACCC-C4D6BBC8BE68@microsoft.com...
> "Staffan Gustafsson" wrote:
>
>> This could be represented as a DateTime. The problem is that the property
>> is
>> optional in EXIF.
>> If represented as a string, you can allways return null or String.Empty,
>> but
>> then you lose all the goodness of the strong typing.
>
> Uhh, why do you think a DateTime property can't be null?
> If a String can be null, any other object should be able to be null, too.
>
> --
> greetings
> dreeschkind

Can you query for the availability of a property from a script?
Or how do clients handle the "Maybe it's there" nature of the properties?

Any pointer to a place in the SDK that explains how to add a property?

Sounds like something else than a getter/setter in C#...

Regards

/Staffan



"Jeffrey Snover [MSFT]" <jsnover@microsoft.com> wrote in message
news:%23RdAFiXhGHA.1208@TK2MSFTNGP02.phx.gbl...
> As a general rule, PowerShell is loose about missing values. e.g if you
> specify a value that is not there, it returns a null instead of
> complaining. In the latest release, we've added a the ability to say
> Set-PSDebug -STRICT
> This will throw an exception if you try to access a variable that does not
> exist but it still lets you access properties that don't exist (we'll deal
> with this an other features for -STRICT in V2).
>
> As such, you can either add the properties and give then null values or
> NOT add the properties. There are 2 considerations here:
> 1) SETTING. If you ever want to SET the values, then you should add them
> and give them null properties. Setting a property that does not exist
> causes an exception.
> 2) Resource consumption. You'll want to look at how many null properties
> you'll have in the average case. If that is a lot, you might consider not
> adding them.
>
> --
> Jeffrey Snover [MSFT]
> Windows PowerShell Architect
> Microsoft Corporation
> This posting is provided "AS IS" with no warranties, no confers rights.
>

Sorry about that, I'm just another Java guy.
I always thought .NET was quite similar to Java, where I can do things like
that:

Date d = null;
if (d == null) {
System.out.println("Java");
}

Maybe I should start reading more about .NET and C# now.

--
greetings
dreeschkind

"Staffan Gustafsson" wrote:

> In the .NET type system, a DateTime is a ValueType, allocated on the stack,
> not on the garbage collected head.
>
> The only way you can get a reference to a DateTime is to box it, but then
> you lose the strong typing.
>
>
> PS > [string] $a=$null
> [C:\NeoCode\N2]
>
> PS > [DateTime] $a=$null
> Cannot convert null to type "System.DateTime".
> At line:1 char:14
> + [DateTime] $a= <<<< $null
>
> /Staffan
>
> "dreeschkind" <dreeschkind@discussions.microsoft.com> wrote in message
> news:039BA966-540F-415A-ACCC-C4D6BBC8BE68@microsoft.com...
> > "Staffan Gustafsson" wrote:
> >
> >> This could be represented as a DateTime. The problem is that the property
> >> is
> >> optional in EXIF.
> >> If represented as a string, you can allways return null or String.Empty,
> >> but
> >> then you lose all the goodness of the strong typing.
> >
> > Uhh, why do you think a DateTime property can't be null?
> > If a String can be null, any other object should be able to be null, too.
> >
> > --
> > greetings
> > dreeschkind
>
>
>