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
Tables.jl currently supports column access by Integers and Symbols. Many implementations use Symbols to keep track of column names, such as DataFrames.Index. However, generating too many unique Symbols can lead to memory leaks because Symbols are not garbage collected.
This calls for implementations which use something else, such as Strings or InlineStrings.
Could we add indexing by AbstractStrings to the Tables.jl specification? There could be a fallback definition
but it would be possible to overload this function for a custom table type in order to bypass the conversion to Symbols.
Providing a method for the second argument being of type Symbol would still be mandatory.
In this way, an application consuming the Tables.jl API could use Symbols and AbstractStrings for indexing according to what's most appropriate for the problem at hand, while still supporting all kinds of table types.
The text was updated successfully, but these errors were encountered:
Tables.jl currently supports column access by
Integer
s andSymbol
s. Many implementations useSymbol
s to keep track of column names, such asDataFrames.Index
. However, generating too many uniqueSymbol
s can lead to memory leaks becauseSymbol
s are not garbage collected.This calls for implementations which use something else, such as
String
s orInlineString
s.Could we add indexing by
AbstractString
s to the Tables.jl specification? There could be a fallback definitionbut it would be possible to overload this function for a custom table type in order to bypass the conversion to
Symbol
s.Providing a method for the second argument being of type
Symbol
would still be mandatory.In this way, an application consuming the Tables.jl API could use
Symbol
s andAbstractStrings
for indexing according to what's most appropriate for the problem at hand, while still supporting all kinds of table types.The text was updated successfully, but these errors were encountered: