1. Anders Ruud
  2. love
  3. Issues


Issue #482 wontfix

Removing FileData

Anonymous created an issue

I'm quite not sure why FileData exists.

A lot of types accept Data, however there is no "newData". Generic Data that these types can accept can be created with FileData though.

FileData also has extension and filename properties. Is there any use for these? I know that love.sound.newSoundData checks the file extension, but perhaps if newSoundData could accept Data it could also be given another argument to specify what type of audio it is.

If I'm not misunderstanding anything, my proposal would be:

  • Removing FileData.
  • Creating love.filesystem.newData, which would be like love.filesystem.newFileData without the second "name" argument.
  • Changing the name of the FileDecoder enum to DataDecoder.

Comments (3)

  1. hahawoo

    Uh, I'm pretty sure I was misunderstanding everything. :D

    What I would now propose:

    • Removing the second parameter of newFileData as well as the methods, or, if this information is needed for some reason, moving the second parameter to the third parameter and having it be optional.
    • Changing "Data" to "FileData" on the wiki entries for constructors that accept this type, although I may be misunderstanding something here too.
  2. Bart van Strien

    The extension has a role, and in the rare cases someone uses FileData, I think it is fine this way. Also, in most cases Data is indeed what is supported, not FileData, and misrepresenting it is just.. wrong.

  3. hahawoo

    What role does the extension have exactly? Isn't it just for Decoders? And if so, wouldn't something like this be more suitable:

    love.sound.newDecoder(filedata, 'ogg')

    In any case, it seems that the lover has to make up a name which really has no use other than the extension, which (as far as I know) is only used for Decoders (and I guess SoundData and Sources by extension).

  4. Log in to comment