You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the handles for different implementation (e.g. FilesystemHandle, S3Handle)
have different members that represent the identifier of the root container (File), e.g. path for filesystem and bucket, bucketName for S3.
The different identifiers need to also be present in the Base class and then need to be implemented by all Deriving clases (where the implementation throws some error if the type of identifier is not appropriate for the deriving class).
The following design would be more elegant:
The handle only has a generic member identifier for this, which stores the container identifier as string. The deriving classes need to cast this to the proper representations internally, e.g. using fs::path for filesystem or by parsing the url for s3.
The text was updated successfully, but these errors were encountered:
Currently the handles for different implementation (e.g.
FilesystemHandle
,S3Handle
)have different members that represent the identifier of the root container (File), e.g.
path
for filesystem andbucket
,bucketName
for S3.The different identifiers need to also be present in the Base class and then need to be implemented by all Deriving clases (where the implementation throws some error if the type of identifier is not appropriate for the deriving class).
The following design would be more elegant:
The handle only has a generic member
identifier
for this, which stores the container identifier as string. The deriving classes need to cast this to the proper representations internally, e.g. usingfs::path
for filesystem or by parsing the url for s3.The text was updated successfully, but these errors were encountered: