remove UDSEntry from the public KIO API?

[nf2]

Thiago Macieira wrote:
> nf2 wrote:
>   
>> but perhaps there would be another chance to make UDSEntries more
>> generic: by changing
>>
>> class UDSEntry : public QHash<uint, UDSField>
>>
>> to
>>
>> class UDSEntry : public QHash<QString, UDSField>
>>     
>
> I don't think so.
>
> We timed UDSEntry and profiled it. Otherwise it gets slow.
>
> We can submit extra information via metadata if necessary.
>
>   
i think i got a better idea now:

UDSEntry won't inherit QHash anymore. It becomes a regular class with a 
d-pointer.
Internally it might carry a public QHash<uint, UDSField> but later on 
also a public QHash<QString, UDSField>, when moving to a "named" 
attribute model like in GVFS.

class UDSEntryPrivate;
 
class KIO_EXPORT UDSEntry
{
public:
  virtual QString stringValue( uint field );

  virtual long long numberValue( uint field, long long defaultValue = 0 );

  // Convenience methods.
  // Let's not add one method per field, only methods that have some 
more logic
  // than just calling stringValue(field) or numberValue(field).

  /// @return true if this entry is a directory (or a link to a directory)
  virtual bool isDir();
  /// @return true if this entry is a link
  virtual bool isLink();
 
  virtual void set(UDSFieldTypes t, QString string);
 
  virtual void set(UDSFieldTypes t, long long l);
 
private:
   UDSEntryPrivate* const d;

};

For named attributes we can overload the setters and getters without 
breaking the API:

virtual QString stringValue(QString attrName); .

... and so on ...